|
»
« Return to Thread: Refactoring Authenticated/Identified
Re: Refactoring Authenticated/Identified
by Geert Bevin
::
Rate this Message:
Hi Steven,
> What I'd love -- and I'm sure you would too -- would be to get to
> the point where a reasonably skilled developer could write their
> own, say, user database module without having to ever look at the
> RIFE source tree. Not that there's anything bad about having the
> sources to refer to, of course, but if my experience is typical,
> right now things are intertwined tightly enough that someone
> writing custom auth code has to be highly aware of the
> implementation details of the authentication system.
Indeed that would be awesome. I'm wondering, would you be up for
making this refactoring happen? It will be quite a while before I can
look at it. It's really time that I spend as much free time as
possible on the book(s) and the advancement of continuations.
> This refactoring, assuming it turns out to be as feasible as it
> sounds, will definitely help in that area. I was not looking
> forward to figuring out how to explain the current Deployer system
> on the auth internals Wiki page. (Which, BTW, I am about to go work
> on a little more.)
>
>> Of all the previous suggestions that you've made, I think that the
>> fall-through authentication solution seems the best to me (the one
>> that doesn't require a form when no authentication session is
>> present and no remember cookie can be found). It doesn't solve the
>> theoretical use case of people that want to retrieve user
>> credentials of accounts that haven't been registered as users to
>> the authentication back-end yet, but it does solve your "eternal
>> authentication session" problem without introducing an artificial
>> embedded element.
>
> I'm not sure I understand that use case. Can you give me an example?
I was referring to the one I described in an earlier email:
http://www.nabble.com/Re%3A-%22Remember-me%22-for-identified-%28not-
authenticated%29-pages--p5592145.html
> I've just filed RIFE-301 with an initial stab at an implementation
> of the fall-through mechanism. Seems to work just fine.
That looks like a good implementation of it. I would rename
"allow_anonymous" to "enforce_authenticated", feels more logical and
general-purpose to me.
To implement the tests for this, I can point you to the related
files. First, add the required elements to the authentication sites
that are here: http://rifers.org:8088/browse/rifers/rife/trunk/
programs/unittests/config/site
If you want, you can add the individual element XML files here, but I
don't do that anymore: http://rifers.org:8088/browse/rifers/rife/
trunk/programs/unittests/config/element/authentication
Then you add the actual tests to the JUnit suites that are here:
http://rifers.org:8088/browse/rifers/rife/trunk/src/unittests/com/
uwyn/rife/authentication/elements
To run only these, I simple comment out the non authentication test
suites from:
http://rifers.org:8088/browse/rifers/rife/trunk/src/unittests/com/
uwyn/rife/TestRifeTests.java?r=trunk
and only leave the last bunch of server-side test suites in here:
http://rifers.org:8088/browse/rifers/rife/trunk/src/unittests/com/
uwyn/rife/authentication/TestSuiteAuthentication.java?r=trunk
To only use one database for testing, modify this file and prefix the
"unittests*" names with another character (I use 'd' of disabled):
http://rifers.org:8088/browse/rifers/rife/trunk/programs/unittests/
config/rep/unittests_datasources.xml?r=trunk
Hope this is a bit clear, otherwise don't hesitate to ask.
Take care,
Geert
PS.: I know that this would all be much easier if the tests were
converted to TestNG ... but I'm not really up for that test ;-)
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel
> What I'd love -- and I'm sure you would too -- would be to get to
> the point where a reasonably skilled developer could write their
> own, say, user database module without having to ever look at the
> RIFE source tree. Not that there's anything bad about having the
> sources to refer to, of course, but if my experience is typical,
> right now things are intertwined tightly enough that someone
> writing custom auth code has to be highly aware of the
> implementation details of the authentication system.
Indeed that would be awesome. I'm wondering, would you be up for
making this refactoring happen? It will be quite a while before I can
look at it. It's really time that I spend as much free time as
possible on the book(s) and the advancement of continuations.
> This refactoring, assuming it turns out to be as feasible as it
> sounds, will definitely help in that area. I was not looking
> forward to figuring out how to explain the current Deployer system
> on the auth internals Wiki page. (Which, BTW, I am about to go work
> on a little more.)
>
>> Of all the previous suggestions that you've made, I think that the
>> fall-through authentication solution seems the best to me (the one
>> that doesn't require a form when no authentication session is
>> present and no remember cookie can be found). It doesn't solve the
>> theoretical use case of people that want to retrieve user
>> credentials of accounts that haven't been registered as users to
>> the authentication back-end yet, but it does solve your "eternal
>> authentication session" problem without introducing an artificial
>> embedded element.
>
> I'm not sure I understand that use case. Can you give me an example?
I was referring to the one I described in an earlier email:
http://www.nabble.com/Re%3A-%22Remember-me%22-for-identified-%28not-
authenticated%29-pages--p5592145.html
> I've just filed RIFE-301 with an initial stab at an implementation
> of the fall-through mechanism. Seems to work just fine.
That looks like a good implementation of it. I would rename
"allow_anonymous" to "enforce_authenticated", feels more logical and
general-purpose to me.
To implement the tests for this, I can point you to the related
files. First, add the required elements to the authentication sites
that are here: http://rifers.org:8088/browse/rifers/rife/trunk/
programs/unittests/config/site
If you want, you can add the individual element XML files here, but I
don't do that anymore: http://rifers.org:8088/browse/rifers/rife/
trunk/programs/unittests/config/element/authentication
Then you add the actual tests to the JUnit suites that are here:
http://rifers.org:8088/browse/rifers/rife/trunk/src/unittests/com/
uwyn/rife/authentication/elements
To run only these, I simple comment out the non authentication test
suites from:
http://rifers.org:8088/browse/rifers/rife/trunk/src/unittests/com/
uwyn/rife/TestRifeTests.java?r=trunk
and only leave the last bunch of server-side test suites in here:
http://rifers.org:8088/browse/rifers/rife/trunk/src/unittests/com/
uwyn/rife/authentication/TestSuiteAuthentication.java?r=trunk
To only use one database for testing, modify this file and prefix the
"unittests*" names with another character (I use 'd' of disabled):
http://rifers.org:8088/browse/rifers/rife/trunk/programs/unittests/
config/rep/unittests_datasources.xml?r=trunk
Hope this is a bit clear, otherwise don't hesitate to ask.
Take care,
Geert
PS.: I know that this would all be much easier if the tests were
converted to TestNG ... but I'm not really up for that test ;-)
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel
« Return to Thread: Refactoring Authenticated/Identified
| Free embeddable forum powered by Nabble | Forum Help |
