Fred, you seem to have trouble to divide the architecture in its
different modules. The authentication elements just provide one a
specific interface to do authentication. This has got nothing to do
with the Credentials, CredentialsManager, SessionsManager and
SessionValidator in interfaces. You can use there manager classes to
build any kind of authentication interface, including HTTP
authentication.
Forget about the concrete elements, and instead of using forms,
request parameters, cookies, ... just implement an authentication
element that does what HTTP authentication needs and use the
interfaces above for the backend.
On 5-dec-05, at 19:40, F Baube wrote:
Surely sendmail reeled when thusly spake Geert Bevin:
Fred, what is important for you, to have HTTP Authentication or to
access tomcat's database?
That is indeed precisely the right question to ask :)
The short answer is: HTTP Authentication.
The longish answer is: It appears that Rife is
architected to be incompatible with HTTP Basic
authentication ... BUT this is easily fixed.
I would implement HTTP Authentication using RIFE's RoleUser
credentials and authentication session managers. This gives you
container independence and easy migration in case you need it.
I guess then you are referring to the instructions given at
http://rifers.org/wiki/display/RIFE/Flexible+authentication
The relevant classes appear to be
com.uwyn.rife.authentication.credentials.RoleUser
com.uwyn.rife.authentication.elements.Authenticated
com.uwyn.rife.authentication.elements.RoleUserAuthenticated
and possibly also
DatabaseAuthenticated, MemoryAuthenticated, MixedAuthenticated
It seems tho that actually the existing authentication classes
could be lightly modified to conform to HTTP Basic authentication.
Currently, when authentication fails, Rife replies with an HTTP
response "200 OK" (!) This will _not_ trigger the appropriate
behavior in client apps (like browsers !) which look for a "401
Unauthorized" and, if it is found, generate a login dialog.
For example, a standalone WebDAV-capable editor application knows
to display a login dialog when it gets a "401", and it feels free
to ignore the HTML response body. This is also how Tomcat's
"manager" servlet operates.
I would suggest that class Authenticated could be given a new
boolean configuration parameter (say, "httpbasic") which would
direct the Element to
(a) respond to login failure with "401 Unauthorized"
(plus an [optional?] login template), and
(b) set the childTrigger if (and only if) the
"Authorization:" response header is valid.
Does this sound correct ?
fred
--
F.Baube *
Georgetown/MSFS/1988 * Act locally.
email fbaube#welho.com * Think pangalactically.
gsm +358 41 536 8192 *
wmd 60°11'10.8"N 24°57'36.9"E
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
