Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <AF05ADF1-ED3D-47FF-91BD-D49FC63E9A36@mac.com>
From: Andrew Jaquith <andrew.jaquith@mac.com>
To: "jspwiki-dev@incubator.apache.org" <jspwiki-dev@incubator.apache.org>
In-Reply-To: <32C4368E-9269-4369-8643-923C214E8FCD@ecyrd.com>
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Mime-Version: 1.0 (iPhone Mail 4A93)
Subject: Re: Classmapping and final classes
Content-Transfer-Encoding: 7bit
Date: Mon, 21 Jan 2008 16:03:38 -0500
References: <47946462.6020508@ops.co.at>
 <3B670219-16D3-447D-8D58-274C7757AACF@mac.com>
 <EAF23AF8-BD93-49BD-B460-75F4405B6FB0@ecyrd.com>
 <39ED70F7-BE56-4BC2-AB37-C37630F5CC7F@mac.com>
 <32C4368E-9269-4369-8643-923C214E8FCD@ecyrd.com>

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 <Janne.Jalkanen@ecyrd.com>  
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