Geert Bevin wrote:
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.
Yep, that's it exactly. For some of my pages I just want identification. I was already putting my sensitive pages behind a "no remember allowed" Authenticated element.
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.
That would be nice too -- you could use roles to distinguish between confirmed and unconfirmed users (and just restrict the sensitive areas of the site to the "confirmed" role) but I guess there still needs to be application logic to generate the unique URL, email it to the user (given that RIFE has no built-in concept of a user having an email address) and add the appropriate role to the user once the link is followed.
How much of that necessarily has to be application logic and how much of it RIFE could provide as built-in services, I'm not entirely sure, but based on how often I see it, "click a link in the confirmation email before we let you access the whole site" seems like a very common thing for people to want to do. (I will want it on this project, in fact; I was assuming I'd just roll my own.) It also feels like something that *could* be made fairly generic.
Your suggestion of making authentication always 'fall through' might be workable, but I'm not entirely sure that it's really what is needed.
I will take this over to the devel list, since it will quickly get down to a level of detail that most people won't care about. Assuming it's not there already.
Thanks a lot for the comment on TSS, it really made my day :-)
My pleasure -- everything I said is true. -Steve _______________________________________________ Rife-users mailing list [email protected] http://lists.uwyn.com/mailman/listinfo/rife-users
