Janne- I do not want to get into a philosophical debating match over
extensibility generally speaking. I do, however, want to you to
understand that the two classes we are talking about, specifically,
were not meant to be extended. That is to say, I did this 100%
intentionally. There are other parts of the auth API that are
specifically designed to be hacked - such as the JAAS login stack and
the Authorizer classes. We also have, I would point out, a way of
disabling the authorization checks *entirely*.
Do we know whether any of these methods would satisfy the need? I
don't think we do. That is why I'm suggesting here is that we get a
least a JIRA bug filed about embedding, or whatever the purpose of
this is for. Is that so much to ask?
But it is a bit much to ask to just arbitrarily change a very, very
sensitive class just because of a single email on the dev list. Let us
not treat this matter so casually.
On Jan 21, 2008, at 15:34, Janne Jalkanen <[EMAIL PROTECTED]>
wrote:
On 21 Jan 2008, at 21:05, Andrew Jaquith wrote:
I cannot imagine a class with more security implications than
AuthorizationManager (or AuthenticationManager), can you? :)
Considering that extending it is possible to anyone with access to
source code *anyway* (they just remove the final identifiers), no, I
can't think of any security implications.
The AuthManager classes were deliberately NOT built to be extended.
The Josh Bloch rule applies here: design classes for extension, or
else forbid it.
Yes, but no. The class mapping mechanism we currently have is
really meant for people who hack JSPWiki anyway, but do not want to
apply patches to track changes in the source code all the time, as
even a simple reformatting might invalidate their patch.
We don't have to really to care about design here; only public APIs
and public extension mechanisms.
Here's the other thing. With something so important, I don't want
to just take the easy way out and say, "oh yeah, just extend it."
We can't just casually hack our way around until something works.
We need a scenario, some use cases, a design, and a plan.
"Embedding" sounds like the scenario, but I am just guessing. What
are the use cases? The plan? An enhancement request in JIRA would
be a good start...
I have no idea what people are using it for, but apparently they
are. And I would rather people come up with a way to do it, rather
than we having to make an up-front design which might not do what
people want.
I mean - it's open source. It's not us who is casually hacking
around the code - it's the users. The more power they get, the
better.
Having said that, I'm all for having a proper developer API and
correctly designed extension mechanisms, and use cases and plans and
roadmaps and releases and requirements management and all that jazz,
but to me it feels somewhat odd to say to an open source hacker that
"you can't extend it because we want you to extend only things that
we have decided to be extensible."
/Janne
