Hi Steven,
after reading your mail I actually start to think that we're talking
about different things here. It seems that what's important to you is
to be able to personalize the site for users that have visited
earlier. To me that is very different from authentication, since
authentication makes sure that the accesses are secure, that the
sessions expire, that roles are always verified, etc. This means that
you can rely on it to perform important operations like orders and such.
I think that the solution might be to add a new concept that is not
tied to an authentication session, but that merely allows you to
obtain the user's prior credentials without being actually logged in.
I can imagine that people that are developing a site along the same
lines as the one you're working on, might even want to tailor the
displayed content according to people that are not even properly
registered yet. Someone might for example sign up, but needs to
confirm the account by clicking on a link in a confirmation email. In
the meantime, the content can already be targeted, however nothing
'secure' can happen before the account has actually been activated.
Your suggestion of making authentication always 'fall through' might
be workable, but I'm not entirely sure that it's really what is needed.
Thanks a lot for the comment on TSS, it really made my day :-)
Take care,
Geert
On 01 Aug 2006, at 10:30, Steven Grimm wrote:
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
--
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
