Geert Bevin wrote:
Here's one ugly hack solution to the problem that appears to work and
doesn't require any additional code:
Hmmm, this is not an ugly hack, it makes perfect sense ;-)
It feels like an ugly hack to me for a number of reasons. Foremost, it
is counter to the way the rest of RIFE's authentication works. Except
for this one case, RIFE's authentication is based on a concept of
wrapping the authentication mechanism around an underlying element
implementation such that the implementation does not have to worry about
the details of when and how the authentication happens; it can safely
assume that all the authentication is taken care of by the time it's called.
But in this one particular case, I need to pollute my templates with an
embedded element that doesn't actually produce any output (the only such
in my source base, and, I believe, not a typical thing in RIFE code in
general) and my element implementation needs to be aware of the fact
that its authentication information might be coming from a wrapper or
might be magically appearing the first time it calls getHtmlTemplate(),
depending on whether the user hit another page on the site recently or
not. So, for example, I can't do any logic that depends on whether the
user is known or not until *after* I've fetched my template.
And even barring that, the simple fact that this requires me to declare
an empty template (a fake login form for my authentication element to
display) makes it feel like a hack rather than an elegant, as-intended
use of the framework. Every time an anonymous user hits this page, that
fake "template" has to be executed for the purpose of doing nothing at all.
And the above is all inconsistent: it disappears if I put the page under
an Authenticated parent element rather than an Identified one, meaning
the details of my element implementation are tied to the particulars of
which subsite it's part of.
But I may be wrong. :)
Now that I've had a chance to walk through the authentication code a bit
more in the process of starting to document it, I am reaching the
conclusion that the cleanest way to handle this is to add a config
parameter to Authenticated that allows anonymous access but still runs
through all the remember-me code. Does that sound like a reasonable
approach to you?
My initial thought was that a cleaner way to go was to factor the
remember-me code into a new class that sits between Identified and
Authenticated in the class hierarchy, but then I realized that that new
class would need a bunch of subclasses analogous to
RoleUserAuthenticated and its children. Oh, Java, why do you deny us our
multiple inheritance?!?
You should understand that a rememberid cookie is only valid once. For
logging in a person one time. After that, the regular authentication
functionalities have to take over and a new rememberid cookie is
generated for when the authentication session expires. There's
probably something not entirely set up right so that you're not using
the authid cookie or so.
It is definitely ignoring the authid cookie. I can step through the code
and the rememberid cookie is regenerated on each request before my
template code is even called. For some reason the framework is calling
Authenticated.processElement() and not Authenticated.childTriggered()
even though I can see in my HTTP headers that I'm sending the same
authid value I got back from the last request, and I have specified
authid as the child trigger in my configuration.
But don't worry about it too much -- I think modifying Authenticated is
a cleaner solution anyway, so (unless there's a compelling argument
against it that I'm not seeing) the question will shortly become moot.
-Steve
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
