Torsten Curdt wrote:
In general I agree but it makes the deployment more complicated because the authentication differs from container to container.
The container-specific part of the configuration varies, but it's usually not that complicated. And everyone who has ever deployed a J2EE webapp should know it well.
Anyway, the current implementation of authentication in Linotype is a toy, so you'd have to rewrite it for a realistic deployment, and whoever wants to deploy Linotype using a different user repository, LDAP for example, or support single sign-on, would have to rewrite it once again.
J2EE has a standardized, declaratively specified, authentication mechanism for web apps, that is good enough for Linotype and most apps. Why reinvent it?
Well, there is a big reason: ease of deployment.
*bzzzt*... this is *exactly* what container managed security buys you. At a price of some configuration (but, hey, it's really easy stuff), you get integration with your own AAA architecture, no matter what is it (Basic, Digest, Form, Client cert as mechanism, flat files, SQL, LDAP, you-name-it as user repository).
Now, whether this is suitable for a personal blogging engine, this is quite disputable and I can see your point somehow, but for more complex applications I see no other way. Why reinvent wheels all over? During the past years I've see all kinds of self-baked AAA solutions and _very few_ of them were HTTP compliant (and IIRC, Linotype actually isn't) since they were just layered on top (as in HTTP 200 all over instead than 401's with authentication performed per request).
Linotype will be block and people will want us to deploy a block and forget about it.
Uh-oh, this brings a big issue on the table. You will have a hell of a hard time to convince me that Cocoon (blocks) shouldn't support container managed authentication. If you're serious about HTTP security, you cannot just forget about CMA, since you will have to forget about pluggable authentication mechanism, pluggable authentication layers, SSL aware logins, single sign-on solutions and all the like. Or reinvent them (and maintain them!) yourself. SoC, mate: authentication is part of the HTTP protocol, let's use it the way it was designed. :-)
We don't spend 18 months of design to come up with something that is totally hotdeployable and rewritable and then you throw it down the drain because you have to restart the container because you have to add your own little thing in the webapp deployment descriptor.
I'm all for finding a better solution, but I really can't see any ATM, apart from (again) just reinventing stuff.
>
Why reinvent what J2EE sucked at?
This is not J2EE, this is plain HTTP. You can re-invent it, if you wish, but you'll have to reinvent a huge pile of stuff.
well, I thought that was the reason to
for doing cocoon in the first place.
I'm all for a better authentication strategy but if this doesn't work with our way of doing stuff, well, it's not going to help anybody.
We would need to maintain examples for the different containers... The login page might also need to be different per container.
We can easily provide a configuration for Jetty, since that's what we distribute for running the examples (I already did and will commit it soon). Adding another one for Tomcat wouldn't be a problem at all.
See, that's exactly what I mean.
Well, this is not the case actually. I would ship an _open_ Linotype (yeah, no username/password) and instruct people to protect it using their favourite strategy. This is, after all, what well-behaved Apache applications do: auth belongs to <Directory> or .htaccess.
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
