You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jan Borsodi <jb...@ez.no> on 2002/09/04 13:17:04 UTC
User problem
I have a problem with users in Subversion (I'm using 0.14.2). It seems that all
commits made to the repository is done with the user "anonymous" instead of the
user I've checked out the repository with. I tried looking trough the
documentation (faq and cookbook) for information on this but found none.
Any clues?
And secondly when are roles planned, or should this be done with the pre-commit
hooks?
--
- Jan Borsodi <jb...@ez.no> - Systems Engineer @ eZ systems - Web: http://ez.no
QtVu: http://www.qtvu.org - RegExplorer: http://regexplorer.sourceforge.net
EMacro: http://emacro.sourceforge.net - Apollo: http://www.apolloplayer.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: User problem
Posted by Jan Borsodi <jb...@ez.no>.
Ben Collins-Sussman <su...@collab.net> writes:
> Jan Borsodi <jb...@ez.no> writes:
>
> > Jan Borsodi <jb...@ez.no> writes:
> >
> > > Ben Collins-Sussman <su...@collab.net> writes:
> > >
> > > > If you do get prompted for a password, then we need a network trace of
> > > > the commit. Use ethereal or something to capture the http dialogue,
> > > > and post it here.
> >
> > Here's the log, I checked out a simple directory (password required) and used
> > the -N option to keep the HTTP traffic low. I then added a directory and
> > committed (no password required).
>
> Did you see the last mail from someone else on the list? It was a
> good catch; you're using Limit instead of LimitExcept.
>
> In other words, you've got the reverse behavior you want. You're
> requiring a password on read operations, but not write operations.
> That's why a password was required to checkout (when it shouldn't be),
> and when you committed, Apache never bothered to issue an auth
> challenge at all.
Yup, I understand that now, many thanks for your help.
--
- Jan Borsodi <jb...@ez.no> - Systems Engineer @ eZ systems - Web: http://ez.no
QtVu: http://www.qtvu.org - RegExplorer: http://regexplorer.sourceforge.net
EMacro: http://emacro.sourceforge.net - Apollo: http://www.apolloplayer.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: User problem
Posted by Jan Borsodi <jb...@ez.no>.
Ben Collins-Sussman <su...@collab.net> writes:
> Jan Borsodi <jb...@ez.no> writes:
>
> > Jan Borsodi <jb...@ez.no> writes:
> >
> > > Ben Collins-Sussman <su...@collab.net> writes:
> > >
> > > > If you do get prompted for a password, then we need a network trace of
> > > > the commit. Use ethereal or something to capture the http dialogue,
> > > > and post it here.
> >
> > Here's the log, I checked out a simple directory (password required) and used
> > the -N option to keep the HTTP traffic low. I then added a directory and
> > committed (no password required).
>
> Did you see the last mail from someone else on the list? It was a
> good catch; you're using Limit instead of LimitExcept.
>
> In other words, you've got the reverse behavior you want. You're
> requiring a password on read operations, but not write operations.
> That's why a password was required to checkout (when it shouldn't be),
> and when you committed, Apache never bothered to issue an auth
> challenge at all.
I added the LimitExcept in the config but it didn't help with anything. All
commits are still done as 'anonymous'. I also checked the network traffic with
ethereal and Apache DID issue an auth challenge. The reply from the client also
included the auth key.
What's wrong?
--
- Jan Borsodi <jb...@ez.no> - Systems Engineer @ eZ systems - Web: http://ez.no
QtVu: http://www.qtvu.org - RegExplorer: http://regexplorer.sourceforge.net
EMacro: http://emacro.sourceforge.net - Apollo: http://www.apolloplayer.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: User problem
Posted by Ben Collins-Sussman <su...@collab.net>.
Jan Borsodi <jb...@ez.no> writes:
> Jan Borsodi <jb...@ez.no> writes:
>
> > Ben Collins-Sussman <su...@collab.net> writes:
> >
> > > If you do get prompted for a password, then we need a network trace of
> > > the commit. Use ethereal or something to capture the http dialogue,
> > > and post it here.
>
> Here's the log, I checked out a simple directory (password required) and used
> the -N option to keep the HTTP traffic low. I then added a directory and
> committed (no password required).
Did you see the last mail from someone else on the list? It was a
good catch; you're using Limit instead of LimitExcept.
In other words, you've got the reverse behavior you want. You're
requiring a password on read operations, but not write operations.
That's why a password was required to checkout (when it shouldn't be),
and when you committed, Apache never bothered to issue an auth
challenge at all.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: User problem
Posted by Jan Borsodi <jb...@ez.no>.
Jan Borsodi <jb...@ez.no> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > If you do get prompted for a password, then we need a network trace of
> > the commit. Use ethereal or something to capture the http dialogue,
> > and post it here.
Here's the log, I checked out a simple directory (password required) and used
the -N option to keep the HTTP traffic low. I then added a directory and
committed (no password required).
Re: User problem
Posted by Nicholas Riley <nj...@uiuc.edu>.
On Wed, Sep 04, 2002 at 05:19:40PM +0200, Jan Borsodi wrote:
> Changing the Limit to LimitExcept (as noted in the other reply)
> won't help with this, will it?
Yes, it will. You are limiting access to reading, but not to
writing. That's exactly the reverse of what you want to do.
--
=Nicholas Riley <nj...@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
Pablo Research Group, Department of Computer Science and
Medical Scholars Program, University of Illinois at Urbana-Champaign
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: User problem
Posted by Jan Borsodi <jb...@ez.no>.
Ben Collins-Sussman <su...@collab.net> writes:
> Jan Borsodi <jb...@ez.no> writes:
>
> > The server is setup with basic authentication, I use:
> >
> > <Location /svn/nextgen>
> >
> > # Order deny,allow
> > # Deny from all
> > # Allow from .ez.no
> >
> > DAV svn
> > SVNPath /var/www/nextgen
> >
> > # Limit write permission to list of valid users.
> > <Limit GET PROPFIND OPTIONS REPORT>
> > # Require SSL connection for password protection.
> > # SSLRequireSSL
> >
> > AuthType Basic
> > AuthName "Authorization from zev"
> > AuthUserFile /var/www/nextgen/svn.user
> > Require valid-user
> > </Limit>
> > </Location>
> >
> > But still I only get the "anonymous" user on commits, what's wrong?
>
> If you checkout a fresh working copy over http, and then attempt to
> commit, does the client prompt you for a password?
Yup.
> If you do get prompted for a password, then we need a network trace of
> the commit. Use ethereal or something to capture the http dialogue,
> and post it here.
I'll try it out.
Changing the Limit to LimitExcept (as noted in the other reply) won't help with
this, will it?
--
- Jan Borsodi <jb...@ez.no> - Systems Engineer @ eZ systems - Web: http://ez.no
QtVu: http://www.qtvu.org - RegExplorer: http://regexplorer.sourceforge.net
EMacro: http://emacro.sourceforge.net - Apollo: http://www.apolloplayer.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: User problem
Posted by Ben Collins-Sussman <su...@collab.net>.
Jan Borsodi <jb...@ez.no> writes:
> The server is setup with basic authentication, I use:
>
> <Location /svn/nextgen>
>
> # Order deny,allow
> # Deny from all
> # Allow from .ez.no
>
> DAV svn
> SVNPath /var/www/nextgen
>
> # Limit write permission to list of valid users.
> <Limit GET PROPFIND OPTIONS REPORT>
> # Require SSL connection for password protection.
> # SSLRequireSSL
>
> AuthType Basic
> AuthName "Authorization from zev"
> AuthUserFile /var/www/nextgen/svn.user
> Require valid-user
> </Limit>
> </Location>
>
> But still I only get the "anonymous" user on commits, what's wrong?
If you checkout a fresh working copy over http, and then attempt to
commit, does the client prompt you for a password?
If not, something is wrong. That means apache isn't issuing a
challenge for some reason... maybe it can't find the AuthUserFile or
something.
If you do get prompted for a password, then we need a network trace of
the commit. Use ethereal or something to capture the http dialogue,
and post it here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: User problem
Posted by Nicholas Riley <nj...@uiuc.edu>.
On Wed, Sep 04, 2002 at 04:40:36PM +0200, Jan Borsodi wrote:
> # Limit write permission to list of valid users.
> <Limit GET PROPFIND OPTIONS REPORT>
^^^^^^
You want 'LimitExcept', not 'Limit'.
--
=Nicholas Riley <nj...@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
Pablo Research Group, Department of Computer Science and
Medical Scholars Program, University of Illinois at Urbana-Champaign
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: User problem
Posted by Jan Borsodi <jb...@ez.no>.
Ben Collins-Sussman <su...@collab.net> writes:
> Jan Borsodi <jb...@ez.no> writes:
>
> > I have a problem with users in Subversion (I'm using 0.14.2). It
> > seems that all commits made to the repository is done with the user
> > "anonymous" instead of the user I've checked out the repository
> > with. I tried looking trough the documentation (faq and cookbook)
> > for information on this but found none. Any clues?
>
> Yes, I think we need to document how authentication/authorization
> works in the current incarnation of mod_dav_svn... I'll put it in the
> Handbook.
>
> In a nutshell:
>
> When you set up a <Location> block with no
> authentication/authorization directives in it, the repository is
> world-readable and world-writable. In this situation, mod_dav_svn
> can't tell one client apart from another; all incoming http requests
> look the same, so it attributes each commit to an "anonymous" user.
>
> If you activate some kind of authentication in your <Location> block
> (such as basic auth), then the server will challenge each client to
> provide user credentials. The client has all sorts of code for
> discovering and caching username/password info. mod_dav_svn notices
> the validated 'username' field in the incoming apache request, and
> uses that name as the author of the newly committed revision.
>
> So look in the Handbook again... try turning on Basic Auth for write
> operations.
The server is setup with basic authentication, I use:
<Location /svn/nextgen>
# Order deny,allow
# Deny from all
# Allow from .ez.no
DAV svn
SVNPath /var/www/nextgen
# Limit write permission to list of valid users.
<Limit GET PROPFIND OPTIONS REPORT>
# Require SSL connection for password protection.
# SSLRequireSSL
AuthType Basic
AuthName "Authorization from zev"
AuthUserFile /var/www/nextgen/svn.user
Require valid-user
</Limit>
</Location>
But still I only get the "anonymous" user on commits, what's wrong?
--
- Jan Borsodi <jb...@ez.no> - Systems Engineer @ eZ systems - Web: http://ez.no
QtVu: http://www.qtvu.org - RegExplorer: http://regexplorer.sourceforge.net
EMacro: http://emacro.sourceforge.net - Apollo: http://www.apolloplayer.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: User problem
Posted by Ben Collins-Sussman <su...@collab.net>.
Jan Borsodi <jb...@ez.no> writes:
> I have a problem with users in Subversion (I'm using 0.14.2). It
> seems that all commits made to the repository is done with the user
> "anonymous" instead of the user I've checked out the repository
> with. I tried looking trough the documentation (faq and cookbook)
> for information on this but found none. Any clues?
Yes, I think we need to document how authentication/authorization
works in the current incarnation of mod_dav_svn... I'll put it in the
Handbook.
In a nutshell:
When you set up a <Location> block with no
authentication/authorization directives in it, the repository is
world-readable and world-writable. In this situation, mod_dav_svn
can't tell one client apart from another; all incoming http requests
look the same, so it attributes each commit to an "anonymous" user.
If you activate some kind of authentication in your <Location> block
(such as basic auth), then the server will challenge each client to
provide user credentials. The client has all sorts of code for
discovering and caching username/password info. mod_dav_svn notices
the validated 'username' field in the incoming apache request, and
uses that name as the author of the newly committed revision.
So look in the Handbook again... try turning on Basic Auth for write
operations.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org