In reference to ticket #26 when updating submission fields the button say "Add Fields" instead of "Update fields"

When the whislteblower tip is shown, the list of SHA1 fiel hashes of the file are shown with an "on mouse over" effect.

The box in which the sha1 checksum is shown is too small for the Sha1.

Additionally it's not possible for the user to copy&paste that SHA1 hash because it display-out almost immediately as the mouse move over another file.

If the admin try to update two time any kind of fields of the node, during the same session, the second it it try to click "Update" it receive an invalid input format error from server.

While configuring a receiver is possible to configure it also without configuring an email address.

Without an email address the receiver would not be able to log-in to access the receipt.

For that reason the email field of Receiver should be mandatory, enforced on GLB and GLC.

I've been trying to make the procedure at https://github.com/globaleaks/GlobaLeaks/blob/master/README.md working with submodules.

So that the only git command to be done to checkout the project will be:
git clone --recurse https://github.com/globaleaks/GlobaLeaks.git

But in that case the Submodules of GLClient and GLBackend that get downloaded are old revisions:
(glenv)root@nite:/tmp/GlobaLeaks# git submodule status
9:34 83aa90d GLBackend (remotes/origin/rest-hooks-27-g83aa90d)
bde4c08 GLClient (bde4c08)

It's possible to make the submodules point to the HEAD version of the GLBackend & GLClient to setup the stuff in one command starting from GlobaLeaks git?

When a whistleblower approach the submission it is presented a list of Receiver that should be "Context dependent" .

However all receivers are always shown, regardless the fact that a receiver is part or not of a context.

Even changing "Context" in the context list on submission page doesn't change the list of receiver.

Even creating a receiver with no context associated, make it appear in the list.

The receiver cannot see a list of all it's own active Tip.

Discussing with @vecna we have agreed that there will be two kinds of translations that will happen in GlobaLeaks.

One is related to the content that is configurable by a Node Administrator (Customization)

The other is related to application specific strings that will be translated inside of the client software (Client Translation).

Customization

• Forms Fields (suggestions, names)
• Submission wizard (descriptions)
• Title of the node
• Description of the node

Client translation

• Menu items
• Error messages
• Domain specific naming (e.x. Receipt, Submission Fields, Uploaded files, etc.)

Following the discovery of the bug #30 i was able to finalize (submit) a submission on a receiver that's not associated to a context.

The server and client should both check that a submission can be done only with a receiver that's effectively associated with the context for which it's submitting to.

If a submitted text fields is quite long (it may just be a description) it messup the layout of the Whistleblower wip as shown in the attached file.

Example submitted text is:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The Receiver on Receiver Tip can see "You receipt is" with a string inside.

However that information is only for the Whistleblower.

The solutions could be:

• remove that strings completely
• change that string to something else useful for the receiver

After the recent refactoring the methods used by curtreg to generate the requests for use by emulating a globaleaks client from command line stopped working.

A Globaleaks client making request and automation is required to facilitate testing regardless of the availability of full globaleaks client interfaces and rest implementation.

The goal of the client is to facilitate the development.

Requirements:

• it must be quick to be used and developed
• it must be hackish for very quick modification
• it must be commandline to provide easy scripting (es: first do submission, the add files, then finalize, then come back with receipt to access tip, then a receiver access it, etc)

We do not need this client for:

• performance testing
• automated fuzzing

So, we now have 3 options:

• Python curtreg refactoring
  This probably means changing the logic to hard-code data in the request.
• Scripting with cmdline tools
  Make scripting with command line tools such as curl or other pythonic cmdnline script like https://github.com/jkbr/httpie#json

Testing RESTful API with httpie
http://blogs.operationaldynamics.com/andrew/software/research/testing-restful-apis-with-httpie

Testing RESTFul API with curl/wget
http://blogs.operationaldynamics.com/andrew/software/research/testing-rest-the-hard-way

• Javascript client
  Javascript client can be executed from command line with phantomjs.

It can be automated with jasmine (below example of REST testing with jasmine:
http://blog.founddrama.net/2012/09/headless-javascript-testing-with-jasmine-and-phantomjs/
http://stackoverflow.com/questions/11429332/unit-tests-of-node-js-rest-services-with-mocha-or-jasmine
http://brianstoner.com/blog/testing-in-nodejs-with-mocha/

If the user type something different than an email receive from backend 406 not acceptable

The user can click on "Add new receiver" even if the fields is empty, receiving an invalid input format error from the server.

If an administrator goes over Admin->Advanced Settings-> New Password and type a new password without entering the "old password" the server report a successful operation.

The server should report an invalid operation or missing data

However, the password is not changed.

Receiver cannot autonomously change it's own password by accessing to it's own preference page.

Setup Wizard Page should be removed because it's not part of this early release of GlobaLeaks

When the admin try to configure with "Edit Fields", certain fields type cannot be configured.

That is in particular due to the fields that, while editing, does require to add multiple sub-data when a new "Add options" button appear, but it's not possible from the interface to add "those options" .

The fields that cannot be configured from UI are:

• Drop Menu (Select)
• Multi Select
• CheckBoxes

The interface doesn't show the logo of the initiative (even if manually configured, we should place something where the logo above-left say "140x140") .

When the whistleblower type it's own receive, he cannot use the keyboard to confirm the receipt submission, but he must mandatory click "View Tip" with his mouse.

When the whistleblower decided to log-out from his tip page, he is now redirected to the /login page asking for username and password.

But this page is only for receivers and admin.

The whistleblower should be redirected to the main page, when he can back use a receipt to login again.

Password lockout is to protect receivers against password brute forcing, functionally as described in the "GlobaLeaks Application Security Design" document.

This feature is to be implemented by:

• making the lockout parameters configurable by the admin
• visualizing remaining attempt on "failed password attempt" (the user must be informed that he has remaining X passwords while typing)
• introducing the concept of receiver activated/deactivated flag
• the logging of the security incident (somehow to report the admin some info about what's happened, even as a receiver flag containing some info about the incident)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

When admin access with his browser http://dev.globaleaks.org:8082/login it get 405: Method Not Allowed and it's now shown the login page

In the upper part of the Whistleblower tip it's your "Your Receipt is" with the goal to remind the Whistleblower about his Receipt.

The currently show Receipt is 00000000-0000-0000-0000-100000001293 that's not the Receipt.

The text should be, or removed, or filled with Receipt.

After a admin or receiver login they are not redirected to the main page (main config for admin or tip list for receiver).

In the spec $contextDescriptionDict is not specified anywhere. @vecna

The Whistleblower cannot add new files on his Whistleblower Tip page.

This is one of the minimal feature part of globaleaks, as tested by the functional test and should be implemented:
https://docs.google.com/a/apps.globaleaks.org/document/d/1ZBtY0dyX7uCW_6ZCf5K2QHKQJkbGPZ1HOuHxkBqh3yw/edit#

The Receivers does not receive an email notification (on adding of new files from whistleblower), after #33 has been implemented
Looking from console log i didn't see attempt to send emails.
It maybe related to #19 or not.

The result is that Receivers get notified by email when a whistleblower add new files.

The Receivers does not receive a notification (on comments from whistleblower or other receivers).
Looking from console log i didn't see attempt to send emails.
It maybe related to #19 or not.

The result is that Receivers get notified by email when a whistleblower or another receiver send a comment.

A whistleblower can finalize submission while a file upload is in progress.

When an upload is in progress, the user should be prevented from finalizing a submission.

There is some concrete bug related to the association between receivers and context.

a) The receivers, even if not added, are show like associated only to the first context in the list
b) Is not possible to add new context to receivers (doesn't even know in the list box)
c) Is not possible to add new receivers to a context (there is the list of receiver in the list box, but after a "save" and a Realod Ctrl+R of the overall page, the receivers are not saved to the context)

There is something broken in the logic/data between receivers/context association

When a user access the login page, it's not shown directly it's main page (for it's role, receiver or admin), but it's presented again the "login" inquiry

Those fields does not validate to the corresponding required value:

Hidden Service: hiddenservice.blahblah (can input any string)
Public Page: hiddenservice.blahblah (can input any string)

When admin click "Add receiver" fields near the next"Add Receiver" button (to add another receiver) is pre-filled with the name of the previously added receiver.

The new "Add Receiver" fields should be empty because the admin for sure doesn't want to add another receiver with the same name of the previous one.

The Receivers does not receive an email notification (on submission from whistleblower).
Looking from console log i didn't see attempt to send emails.
It maybe related to #19 or not.

The result is that Receivers get notified by email when a whistleblower apply for a submission.

We need to figure out what's the best way (simpler, flexible and safe) for share date between client, server and possible third party services integrated with our environment.

The date fields in the client-server communication would describe system-dependent-date, like "when this Tip has been submitted" or "when this context has been created in the node".

The base idea was: using simply 32bit time_t description, (representing the number of seconds after 1970) because is supported in every language a function able to convert this element in an human readable format, and would be stored and compared easily.

In this way, we can decide in different situation if a date need to be rendered with a certain localization method (eg, in the client with japanese lang, without having to parse a western based date string).

other options (need to be evaluated) are:
http://docs.python.org/library/datetime.html?highlight=date%20format
http://en.wikipedia.org/wiki/ISO_8601
http://www.ietf.org/rfc/rfc3339.txt

useful pointer: http://stackoverflow.com/questions/455580/json-datetime-between-python-and-javascript

Tticket expected output is: "the safest and easier way for timedate portability among different programming languages and different calendar localization".

@hellais @evilaliv3 @fpietrosanti

The admin interface for the notification settings does not save and does not valdate the data provided as input.

After saving, the data are not shown in the web interface (empty fields) even after a reload.

Additionally it does not do client validation on the following fields format:
SMTP server address
SMTP server port
Username
Password
Transport Security

After a user made many actions the informational tooltip (displaying invalid input formats or "operation success!") accumulate and does not disappear from the user web page.

Two (or more than two) receivers can be created with same name and email that are parameters required to be unique (because the name is shown in submission page and the second is used as a username for receiver).

This should be enforced both on client and server

Are the UI mockups going to be available in the repository so that people can work on implementing them?

If the admin create a context without giving a name the context, both the client and the server accept to create and save a context without "a name" .

The client and the server should not accept a context without a name.

The Tip (Whistleblower and Receiver) have a column with a table for the receiver showing 3 row:

• name
• description
• access count

The field description is never used and always empty

The fix can be done in two way:

• to add a description to the reicever (making it configurable via admin as an additional fields)
• or
• to remove the description field in the Receiver list of Tip Page

The Basic Config page doesn't load in certain condition

If an unauthenticated admin goes to

http://dev.globaleaks.org:8082/#/admin/basic

then it got redirected automatically to /#/login

and it authenticate with login and password

then it got redirected to the Basic Settings page.

Now the Basic Settings page is empty and the user must hit a reload of the web page Ctrl+R in order to see the fields populated.

Page saw:

After Ctrl+R:

The whistleblower can submit also without clicking "I Agree"

The Receiver name created can be artbitrarly long.

The length should be set to a maximum.

Both the client and the server accept a very long string like:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The fields where the receiver's assignment to the context can be done, doesn't have a label describing it.

As shown in the attached screenshots, after the user has successfully loaded 2 files and is uploading the 3rd one, the layout of the progress bar of file upload is unaligned (on the left-bottom).

When a submission field is created is then not possible to update it, changing it to something else or deleting it.

The only way the user have to change it is to create another context with the new fields from scratch copying the previous one.

The Receiver cannot download the fields uploaded by the Whistleblower, (the file names does not provide any hyperlink to download it)

The Receiver must be able to download files form the Tip

The field Admin->Advanced Settings-> "Public Stats update time" is not required because statistics are not a present feature.