Authentication URL Variables

[GoogleCodeExporter]

/authentication should allow for the following variables, to pre-populate the 
incidents and organizations. This will permit us to send custom links to each 
organization and decrease confusion among users.

type: [NULL,drill,live]
incident: [NULL, <name of incident>]
org: [NULL, <name of organization>]

Thus, a link to 
/authentication?incident=Hurricane%20Sandy%20Recovery&org=MHH-HQ would 
pre-populate the Incident with "Hurricane Sandy Recovery", and choose "MHH-HQ" 
as the organization.

See functional (but ugly) login form attached.

Original issue reported on code.google.com by v...@aarontitus.net on 25 Feb 2013 at 4:59

Attachments:

• login.html

[GoogleCodeExporter]

Do you think Issue 162 should be merged with this issue?

Original comment by v...@aarontitus.net on 25 Feb 2013 at 5:00

[GoogleCodeExporter]

It could be if the following urls are allowed:

* /authentication/ => current form
* /authentication/<incident_short_name> => redirects to login
* /authentication/<incident_short_name>/login => login page with incident fixed
* /authentication/<incident_short_name>/login/<org> => login page with incident 
and org fixed

(ignoring incident type here)

Original comment by cpw...@gmail.com on 5 Mar 2013 at 6:37

[GoogleCodeExporter]

That's a step in the right direction, although I don't know why we need /login/ 
in the URL, since that's synonymous with /authentication/ (Although if we could 
replace "authentication" with "login," I think that would be great).
Would /<incident_short_name>/authentication/<org> work? If not, how about 
/authentication/<incident_short_name>/<org>? The reason I ask is because, a 
person may want to set a permanent bookmark to their organization and incident, 
and simply click on that link. If they are already logged on, then it should 
automatically forward to the map or Assessment Form.

This raises a bug:
1. Log in.
2. Visit 
https://sandy-helping-hands.appspot.com/authentication?destination=https%3A//san
dy-helping-hands.appspot.com/
3. Server Error (500)

How do you want to deal with the (yet-unimplemented) Drill vs. Live issue? I 
anticipate that the list of drill incident will be separate from the list of 
live incidents.
... Now that I think about it, I guess if we require each incident to have a 
unique short name, including drills, then that shouldn't be a problem.

Original comment by v...@aarontitus.net on 5 Mar 2013 at 6:56

[GoogleCodeExporter]

Either with or without "login" in the url would work - I was including it 
because you do as with "[root]/[incidentshorthand]/login" in issue 162.

Added that bug as issue 214.

I think that's true re drill incidents - they are unique incidents/events.

Original comment by cpw...@gmail.com on 5 Mar 2013 at 7:34

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

/<login or authentication>/<incident_short_name>/<org> could definitely be 
implemented, and /<org> can be optional.

Code note: this may require changing AuthenticatedHandler which currently drops 
route parameters.

Original comment by cpw...@gmail.com on 5 Mar 2013 at 7:39

[GoogleCodeExporter]

Great. Let's do this if possible: [root]/login/<incident_short_name>/<org>

For each of the following, a person who is already logged in will automatically 
forward to [root]. If not logged in:
* [root]/login/<incident_short_name>/<org>: Login page, Incident and Org 
selected in dropdown.  User may chose a different incident or org if they wish.
* [root]/login/<incident_short_name>/: Login page, Incident selected in 
dropdown, and appropriate list of Organizations displayed (Note- this may take 
some work, as the Org list seems to be triggered onChange).
* [root]/login/: Login page, no incident or org chosen.

Original comment by v...@aarontitus.net on 5 Mar 2013 at 8:34

[GoogleCodeExporter]

In contrast:
* [root]/<incident_short_name>: If unauthenticated, then forwards to an 
unauthenticated public map for that incident.  If the user is 
pre-authenticated, then forwards to [root].

Merge Issue 162 into this one.
See Issue 101 for additional login requirements
See Issue 148 for public map requirements

Original comment by v...@aarontitus.net on 5 Mar 2013 at 10:04