Hi Steven,
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.
Exactly, that's the same for remember me support. It's tied to
authentication, not identification. They are different concepts.
Remember me facilitates the user's task by giving them a one-time
ticket that will fill in their credentials automatically into a login
form. It however doesn't allow you to identify them since the
remember me cookie doesn't carr any user information, it needs you to
be logged in first for that. Mixing remember me functionality with
identification blurs the concepts ihmo. As it stands now it's very
clear, you can identify someone that is authenticated, and you can
authenticate them automatically by using a one-time remember me ticket.
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.
No, that's just because you want people to have authentication
functionalities without authenticating them. You say it yourself in
your first paragraph, RIFE's authentication is based on a concept of
wrapping. Hence, you need to wrap something. If you want something
else to execute at all times, you need to embed that wrapping inside
it (the embedded element).
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.
Euhm, I never use it with an empty template, but with a logout button
and a message that identifies the user, including a link to their
profile. This feels very natural to me since the logout button only
appears when users are logged in and when they're not (and don't have
remember me enabled), they still get a normal form to authenticate
themselves.
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.
Again, identification is not authentication. You can walk into a
store and people can identify you as someone that they've heard
about, etc etc. However, they're only able to authenticate and
authorize you when you're able to produce acceptable credentials.
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?
What exactly do you mean by that, making authentication not
mandatory? Ie, not showing the login form when you wrap
authentication around an element? How do people authenticate then
when they arrive at such a page and don't have a remember me cookie?
Will they have to go to a special page in the site that is able to
properly authenticate them? Why then not include a small login form
in the anonymous page and save them the trouble of having to leave
the page and find their way back?
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.
This is very weird, since it's not doing this for me, just check on
http://rifers.org/blogs. You can use remember me there and it only
regenerates it when you have deleted the authid from your cookies.
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.
I'm not sure at all that this is the right approach, see my arguments
above.
Best regards,
Geert
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
