On 2/9/2012 8:32 AM, John Dennis wrote:
Currently when the UI is loaded for the first time it will execute an
ipa_init operation which consists of:
1. Loading I18 messages.
2. Getting user info (whoami).
3. Loading environment variables.
4. Checking whether DNS is enabled.
5. Loading objects& commands metadata for labels and validations.
Right now if the UI detects a change in the principal name or server
version it will reload itself and so it will execute the ipa_init again.
With your patch #61 the UI will automatically renew the session, but if
the principal stays the same it won't execute the ipa_init again.
I think the only thing that might change after session renewal is user
info (#2). The others are pretty much static. So we probably can move
whoami into another method that can be called separately.
I agree this represents a good modification to the client logic however
it don't see how it's specific to sessions. Wouldn't the same hold true
for the current case when the principal changes?
If someone already has a session then changes to another principal, will
he get a new session and then reauthenticate against the login URL? Or
will he use the same session but just reauthenticate?
What if he then changes back to the previous principal, will he reuse
the old session? If so will he be required to authenticate again?
I think if the principal change is always preceded by reauthentication,
the UI will only need to redo the whoami after successful login.
Otherwise, the UI will need to check the principal change after each
operation like in the current code.
Would it be possible for someone from another machine to randomly guess
a session ID and then take over an existing authenticated session?
On top of your changes there would be some additional UI changes:
1. As described above, we need to move whoami out of ipa_init and call
it after each session renewal.
2. The whoami output contains the user's authz info (group/role
membership). We need to redraw the UI components if the user's authz has
changed and make sure they are re-initialized correctly.
3. We need to redirect the user to the UI main page if the current page
is no longer accessible due to authz changes.
O.K. got it, here are my thoughts:
1) The enhanced logic is independent of sessions.
2) We need to test and exercise the new session auth so that code should
be there.
3) However, adding the session logic in item 2 will be affected by the
code changes in item 1.
Therefore both should be done ASAP. We can either add the session code
immediately and modify it later when the code changes in item 1 are done
or put the session changes in immediately and modify it to use the new
logic in item 1 when it's ready.
I don't have strong feelings either way. However I would prefer if you
or another UI guru made the changes you outline above rather than me. I
think that would be more efficient and someone who intimately knows the
UI code would be less likely to introduce a problem I might not be aware
of.
I think the code that is already pushed is fine, except that we loses
the backward compatibility, and your next patch will fix that. After
that the above UI changes can be done separately by the UI team.
The only thing which might be unaccounted for would be if the web UI for
some reason wanted to use the old /ipa/json and not use sessions. It
would need some extra logic to handle this but I don't see any need for
this, after the server is updated to support sessions it sends back an
ipa.js javascript file to the client which always elects to use the
/ipa/session/json URL. If for some reason the browser is still using an
old copy of ipa.js it simply ends up using the old /ipa/json URL without
sessions, which should "just work".
Right, no need to worry about this, the UI will just use one of the
methods.
On the second thought, after some discussions, we might want to support
both cases in case a user cannot/would not use cookies. As long as both
URL's are available, we can figure out later how the UI will use it.
I do think we need a logout button which will invalidate the session
auth. The current patch does not include an RPC command to accomplish
that, but it's on my to-do list. Since we have to redo the patch to
handle both session and non-session auth I could add that in at the same
time (or we could open a new ticket and defer).
Here are the tickets, the logout URL can be added separately if you want:
https://fedorahosted.org/freeipa/ticket/2362
https://fedorahosted.org/freeipa/ticket/2363
--
Endi S. Dewata
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
