Re: svn commit: r584279 - in /maven/archiva/trunk/archiva-web: archiva-security/src/main/java/org/apache/maven/archiva/security/ archiva-webapp/src/main/java/org/apache/maven/archiva/web/action/admin/repositories/ archiva-webapp/src/main/java/org/apa

[Wendy Smoak <ws...@gmail.com>]

On 10/12/07, joakime@apache.org <jo...@apache.org> wrote:
> Author: joakime
> Date: Fri Oct 12 14:35:41 2007
> New Revision: 584279
>
> URL: http://svn.apache.org/viewvc?rev=584279&view=rev
> Log:
> [MRM-398] configure guest access by default for pre-configured repositories
> Newly added repositories are assigned to the guest user in read-only mode.

As mentioned on the issue comments, this isn't what was requested.
Brett and I both want a way to pre-configure guest access "out of the
box" for pre-configured repositories.

I don't think it's a good idea to make newly added repositories
visible by default.

-- 
Wendy

Re: svn commit: r584279 - in /maven/archiva/trunk/archiva-web: archiva-security/src/main/java/org/apache/maven/archiva/security/ archiva-webapp/src/main/java/org/apache/maven/archiva/web/action/admin/repositories/ archiva-webapp/src/main/java/org/apa

[Brett Porter <br...@apache.org>]

What Wendy said :)

- we should roll back the commit, I don't think it's a good idea in  
general (and IIUC, it doesn't apply the changes for the pre- 
configured repos at all)
- if we agree to pre-configure the repos, we need to seek a simpler  
solution.

Joakim - I'm a little confused about the purpose of your mail -  
everything screamed that you thought the solution was a bad idea and  
then you suggested you might go ahead with it :) Just saying, it was  
a bit hard to grok what exactly you were getting at doing. (There are  
also reasons the math about how many components.xml would be touched  
and what might get dragged in to test it that weren't quite right,  
but it's a non-issue if the solution is different - it was more  
related to the fact that dragging all that stuff into configuration  
was clearly a bad idea).

Off the top of my head, I would think we should assign the  
permissions in the current code that checks for existence of roles on  
startup, and only when the roles did not previously exist. This will  
only get hit for the pre-configured repos - those added later will  
create the roles themselves and not configure any permissions. It  
should check the ID name against the default ones so it doesn't  
automatically assign to all those pre-configured by hand. If you are  
not content that is robust enough, I'd be happy with a flag  
<preconfigureGuestAccess>true|false</preconfigureGuestAccess> in the  
repository configuration that can be added to default-archiva.xml but  
is false by default.

Is that a better way to go?

Cheers,
Brett

On 13/10/2007, at 10:43 PM, Wendy Smoak wrote:

> On 10/12/07, Joakim Erdfelt <jo...@erdfelt.com> wrote:
>
>> I can only think of 1 place for this.
>> When DefaultArchivaConfiguration loads the default-archiva.xml  
>> from its
>> resources location and puts it into place.
>
> That makes sense on a high level, but there's rarely only one way to
> do something.  Before we go further with this I'd like to see more
> discussion around the 'pre-configure guest access' feature.
>
> For now, do we all agree that this commit wasn't what was intended by
> MRM-398 and should be reverted?
>
>> That should be a 4 part commit (once split by apache's commit message
>> email split routines)
>> And that's the bare minimum work.
>> It's likely that archiva-security goes away, and archiva- 
>> configuration
>> gains a bunch of security.
>>
>> Ready for it?
>
> Once again, it's not necessarily length, it's complexity (unrelated
> changes) and the amount of communication around the change.
>
> For example, I raised a concern about this commit, which fit nicely
> into one message, because I don't think it's what we 'agreed on' by
> opening and scheduling the issue.
>
> -- 
> Wendy

--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/

Re: svn commit: r584279 - in /maven/archiva/trunk/archiva-web: archiva-security/src/main/java/org/apache/maven/archiva/security/ archiva-webapp/src/main/java/org/apache/maven/archiva/web/action/admin/repositories/ archiva-webapp/src/main/java/org/apa

[Wendy Smoak <ws...@gmail.com>]

On 10/12/07, Joakim Erdfelt <jo...@erdfelt.com> wrote:

> I can only think of 1 place for this.
> When DefaultArchivaConfiguration loads the default-archiva.xml from its
> resources location and puts it into place.

That makes sense on a high level, but there's rarely only one way to
do something.  Before we go further with this I'd like to see more
discussion around the 'pre-configure guest access' feature.

For now, do we all agree that this commit wasn't what was intended by
MRM-398 and should be reverted?

> That should be a 4 part commit (once split by apache's commit message
> email split routines)
> And that's the bare minimum work.
> It's likely that archiva-security goes away, and archiva-configuration
> gains a bunch of security.
>
> Ready for it?

Once again, it's not necessarily length, it's complexity (unrelated
changes) and the amount of communication around the change.

For example, I raised a concern about this commit, which fit nicely
into one message, because I don't think it's what we 'agreed on' by
opening and scheduling the issue.

-- 
Wendy

Re: svn commit: r584279 - in /maven/archiva/trunk/archiva-web: archiva-security/src/main/java/org/apache/maven/archiva/security/ archiva-webapp/src/main/java/org/apache/maven/archiva/web/action/admin/repositories/ archiva-webapp/src/main/java/org/apa

[Joakim Erdfelt <jo...@erdfelt.com>]

I can only think of 1 place for this.
When DefaultArchivaConfiguration loads the default-archiva.xml from its 
resources location and puts it into place.

Catch is, it will require pulling in redback-rbac all the way down to 
archiva-configuration.
Which means archiva-security will likely go away (merged with 
archiva-configuration), with the RoleManager work that Jesse did, it was 
inevitable for the archiva-security to go away.
But wait! there's more! Because of our use of a role with a resource, 
that means we have to pull in RbacManager too. (because RoleManager 
doesn't support that kind of assignment yet, see Jesse & Redback 
1.0-alpha-4 work)
Also, it means that every unit test that uses the 
DefaultArchivaConfiguration object will have to pull in the RoleManager, 
and RBACManager too.
And while we are loading those, we'll either need to configure a 
database everywhere, or use the "memory" role manager to avoid using the 
database.
Which in turn means that all of those component xmls everywhere will 
need to be touched, which at last count,

Big commit coming?
(back of the envelope math)
$ find . -name "*.xml" -exec grep -l DefaultArchivaConfiguration {} \; | 
wc -l
27
$ find . -name "*.xml" -exec grep -n DefaultArchivaConfiguration {} \; | 
wc -l
63

27 files, 63 usages of DefaultArchivaConfiguration.
Average of about 65 new lines needed per DefaultArchivaConfiguration 
definition.
65 * 63 = 4095 lines.
+ 27% diff overhead = 5200 lines

That should be a 4 part commit (once split by apache's commit message 
email split routines)
And that's the bare minimum work.
It's likely that archiva-security goes away, and archiva-configuration 
gains a bunch of security.

Ready for it?

- Joakim

Wendy Smoak wrote:
> On 10/12/07, joakime@apache.org <jo...@apache.org> wrote:
>   
>> Author: joakime
>> Date: Fri Oct 12 14:35:41 2007
>> New Revision: 584279
>>
>> URL: http://svn.apache.org/viewvc?rev=584279&view=rev
>> Log:
>> [MRM-398] configure guest access by default for pre-configured repositories
>> Newly added repositories are assigned to the guest user in read-only mode.
>>     
>
> As mentioned on the issue comments, this isn't what was requested.
> Brett and I both want a way to pre-configure guest access "out of the
> box" for pre-configured repositories.
>
> I don't think it's a good idea to make newly added repositories
> visible by default.
>
>   


-- 
- Joakim Erdfelt
  joakim@erdfelt.com
  Open Source Software (OSS) Developer