On Mar 13, 2009, at 3:58 AM, Bilgin Ibryam wrote:
2. Clickin on lookup button.
3. Ajax events which render screens (like ajax pagiantion and ajax
drop downs).
Have you actually observed either of these? If there are issues like
this anywhere it is because of bad coding. Lookup windows and ajax
requests should always be in the same webapp, and can participate in
the existing session.
The externalLoginKey is only for situations where you are jumping to
different webapps, and there is no reason to do that for lookups and
AJAX stuff (especially since you can generally add about 2 lines of
XML to the controller.xml file to reuse resources even if they are
defined in another component).
-David
For solving 2 and 3 I guess two ways:
Mark some of the requrest (actually better the views in
controller)so they don't generate new externalLoginKeys.
Or add a request parameter to every request which should not
generate new externalLoginKey.
WDYT? Other proposals?
Bilgin
On Mar 12, 2009, at 7:19 AM, David E Jones wrote:
On Mar 11, 2009, at 5:16 PM, Bilgin Ibryam wrote:
Quoting David E Jones <david.jo...@hotwaxmedia.com>:
You may be describing a well known issue, and one that is part of
the
way the externalLoginKey works (so it is not likely to change). The
externalLoginKey allows you to automatically login to another
webapp
without a username/password. In order to do this a new login key is
generated with EVERY request to the server in order to keep it's
life
cycle pretty short. As long as it is on a secure/https page when it
goes to the browser it is pretty safe, but it generally comes
back to
the server in a URL and so needs to be invalidated immediately so
that
it cannot be used again, as that is pretty easy to snoop.
So, to make it not work is easy: just have a page open in your
browser
that has a stale externalLoginKey in its URLS.
1. load a page where you are authenticated in tab/window A
2. right click on a link within the webapp and open it in tab/
window B
3. go back to tab/window A and click on any link that goes to a
webapp
that you are not already logged into and that has an
externalLoginKey
parameter
The externalLoginKey will be stale, so that auto-login will fail
and
you will be presented with the login form.
I was wondering why externalLoginKey is not a cookie? Probably
because of security reasons, but if it was a cookie, it would have
a short life cycle as JSESSIONID cookie (the cookie value will be
updated on every request) and working on many browser tabs at the
same time wouldn't require multiple logins.
That's a good idea. In theory even if the externalLoginKey were
updated with every request the cookie in the browser (if there is
only one cookie) then it would be updated and even other tabs and
windows should use that with their request. There is a still a
chance that 2 requests could end up in a race condition where one
gets in and causes the server-side key to update even though the
other request is on its way out and gets there after the server key
is updated, but still using the old key from the client cookie.
Anyway, this is a good idea and the only reason I can think of to
not do it is the one you mentioned, ie the security of cookies. It
is very easy to spoof cookie domain names and get cookies from
other sites... it's a "feature" of cookies that causes problems.
There may be ways to protect a cookie better, like encrypting it,
but even if the key is secret on the server a fast attacker, or one
that finds a session that has been idle for a while, then it can
still get the encrypted value and the server wouldn't know if it
came from a valid client or a forged one.
Sorry, was thinking out loud... I'm not sure if there is a good
enough way to protect the cookie... and considering that this would
be substitution for the username and password, I'm not sure I like
it (I even have reservations about the current externalLoginKey...
but a better alternative is tricky...).
-David
