Authentication URL Variables

[aarontitus]

Original author: v...@aarontitus.net (February 25, 2013 16:59:29)

/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: http://code.google.com/p/sandy-disaster-recovery/issues/detail?id=201

[aarontitus]

From v...@aarontitus.net on February 25, 2013 17:00:52 Do you think #162 should be merged with this issue?

[aarontitus]

From cpw...@gmail.com on March 05, 2013 18:37:56 It could be if the following urls are allowed:

• /authentication/ => current form
• /authentication/ => redirects to login
• /authentication//login => login page with incident fixed
• /authentication//login/ => login page with incident and org fixed

(ignoring incident type here)

[aarontitus]

From v...@aarontitus.net on March 05, 2013 18:56:35 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 //authentication/ work? If not, how about /authentication//? 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//sandy-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.

[aarontitus]

From cpw...@gmail.com on March 05, 2013 19:34:42 Either with or without "login" in the url would work - I was including it because you do as with "[root]/[incidentshorthand]/login" in #162.

Added that bug as #214.

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

[aarontitus]

From cpw...@gmail.com on March 05, 2013 19:39:59 /// could definitely be implemented, and / can be optional.

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

[aarontitus]

From v...@aarontitus.net on March 05, 2013 20:34:46 Great. Let's do this if possible: [root]/login//

For each of the following, a person who is already logged in will automatically forward to [root]. If not logged in:

• [root]/login//: Login page, Incident and Org selected in dropdown. User may chose a different incident or org if they wish.
• [root]/login//: 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.

[aarontitus]

From v...@aarontitus.net on March 05, 2013 22:04:03 In contrast:

• [root]/: If unauthenticated, then forwards to an unauthenticated public map for that incident. If the user is pre-authenticated, then forwards to [root].

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