First, let me say I appreciate your willingness to discuss this sort of
thing -- even if I'm disagreeing here, the spirit of open discussion is
a very welcome change from the "No, that's not how it works, and if you
think it should be different, go away" attitude I've seen people get
from developers of other open-source packages. I don't expect to
convince you about everything I pipe up about but it's great that you're
at least willing to listen.
Onward:
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.
I believe RIFE actually *does* tie these two concepts together
intimately. There is no way to identify a user without authenticating
him first. Which is fine in and of itself, but there is no way to
authenticate a user without using a "login required" element. That's one
reason this feels like a hack to me, and why it took me a while to
figure out this solution on my own: I have to use a "login required"
element even though I don't actually have any interest in requiring the
user to log in. Anonymous access is fine for this page, but I have to
include an element that, internally, is saying, "The user isn't logged
in! Better stop him in his tracks and make him fill out a login form!"
The fact that I can make that login form 0 bytes in length doesn't make
the architecture of the page feel any cleaner to me.
Taking a step back, it sounds like the root of the disconnect here is
due to a conceptual difference. At the end of the day what I really want
is a login session that never expires (from the point of view of my
application code, even if it's a virtual session made up of a series of
shorter underlying sessions), whereas it sounds like RIFE's concept of
"remember me" is a way to preempt the login form that the system would
otherwise attempt to present to the user each time they visit a page
with personalized contents after their session expires. A subtle
difference, but a difference.
To me, the current behavior basically means that the Identified element
is next to useless without embedding an Authenticated element. If you
just use Identified as documented, the user can click "Remember Me" when
they log into a site with a 20-minute session expiration, and if they
wait 19 minutes before visiting an Identified page, they're fine, but if
they wait 20 minutes, they all of a sudden get the anonymous version of
the page for no reason they can discern (having checked "Remember Me,"
they quite reasonably expect the system to remember them!) and they send
email to the site administrator complaining that they keep getting
logged out.
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).
Not quite: I want to have *identification* facilities without my code,
or my templates, explicitly taking steps to reauthenticate people. It is
RIFE that ties those two concepts together: you can have authentication
without identification but in the case of a user with a valid rememberid
cookie, you can't have identification without authentication.
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.
Agreed. To take that analogy further, they should be able to greet me by
name even if I haven't been there for a while without me producing my ID
card.
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?
Yes, that's exactly what I mean. If the user is either already in the
middle of a valid session or has a valid rememberid cookie, then his
identity can be supplied to my element by the parent element, no
additional code in either my element or my template required. Otherwise
no identity is supplied. Just like the Identified element, but with
Authenticated's automatic renewal of sessions based on the rememberid
cookie.
As for the UI, see, for example, amazon.com: it does not show you a
login form on every personalizable page when you visit anonymously.
There are plenty of other examples. If you want to display an embedded
login form, you then have to design every personalized page with room
for a login and password and "remember me" button, which is screen real
estate you can't use for other UI elements. And on the particular
project where this is an issue, one of our UI design goals is to
minimize the degree to which it looks like we're pressuring users to
register, which means we want to defer showing any login controls until
the user does something that actually requires logging in.
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.
I will take a look at the blog code and see what I'm doing differently.
I'm not sure at all that this is the right approach, see my arguments
above.
Maybe the thing to do is for me to have a whack at implementing it,
since I think a working example will explain what I'm getting at a lot
better than describing it further. Code speaks louder than words, and
all that. Watch for a patch.
-Steve
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
