Re: [viewvc-users] Interaction between svnauthz, authzfile and svn_config_dir

Kim Howard <[email protected]>
Newsgroups gmane.comp.version-control.cvs.viewcvs.user
Message-ID <OFC19C1CBF.2F6727F6-ON802575F2.005AF513-802575F2.005B9410__7652.9840160676$1247503314$gmane$org@eu.panasonic.com>
"C. Michael Pilato" <[email protected]> wrote on 13/07/2009 16:41:45:

> Kim Howard wrote:
> > My configuration is: ViewVC 1.1.1 RHEL4 Subversion 1.5.4
> > 
> > Most of my setup is working as expected but I am having trouble 
getting
> > ViewVC to obey the access permissions defined in my authzfile.
> > 
> > Repository access is via HTTP only.  The repository and ViewVC are on
> > different computers and hence use different instances of Apache but 
both
> > share the same authzfile.  ViewVC prompts for credentials according to
> > its Apache Location directive (which points to the authzfile) but 
these
> > credentials appear not to be used for authenticating against the
> > Subversion server.  Instead, the credentials cached in svn_config_dir
> > appear to be used.  If I remove the cached credentials from
> > svn_config_dir then I see a Python exception because ViewVC is unable 
to
> > authenticate.
> > 
> > Have I misunderstood how all this works?  If so, can anyone help me 
out
> > please?
> 
> You have misunderstood how all this works.  :-)
> 
> There are three layers here:
> 
>     1.  Apache - responsible for getting a valid username from the user
>     2.  ViewVC - responsible for applying authz rules on username's 
behalf
>     3.  VC system - responsible for making repository data available
> 
> In a repos-is-on-a-different-machine-than-viewvc scenario, the layers 
are
> the same.  But there are some interesting dynamics that occur between 
layers
> 2 and 3, namely in the fact that layer 2 might need to supply its own 
set of
> authn credentials to layer 3 in order for layer 3 to provide any answers
> about repository data at all.
> 
> The important thing to realize is that this scenario does not change 
either
> the requirements of layer 3's behavior or the interactions between the 
other
> layers.  Layer 3 (Subversion in this case, be it via direct API access 
to
> the repository or via a remote connection) is responsible for providing
> every bit of information about the repository that ViewVC asks for, 
period.
>  If that layer is choosing to hide pieces of information, it is doing so 
in
> violation of the design.  In other words, you must ensure in your setup 
that
> whatever authn credentials ViewVC is using to connect to your Subversion
> backend (those cached in svn_config_dir) are blessed with universal read
> access to that repository.  Subversion is not allowed to hide 
information
> from ViewVC -- it's ViewVC's job to hide that information from the 
Apache
> user as necessary.
> 
> Does that make sense?
> 
> -- 
> C. Michael Pilato <[email protected]>
> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Yes, that makes perfect sense.  Thanks very much for helping me understand 
what should have been blindingly obvious.  Now it's all working perfectly 
- until I hit another one of my blind spots!

Thanks again
Kim


..............................................................................
Confidentiality Notice
The information contained in this Email, and any attachments, is intended for the named recipients only. It may contain confidential and/or legally privileged information. If you are not the intended recipient, you must not copy, store, distribute or take any action in reliance on it. Any views expressed do not necessarily reflect the views of the company.

If you receive this Email by mistake, please advise the sender by using the reply facility in your Email software and then delete it.
.............................................................................

------------------------------------------------------
http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4255&dsMessageId=2370989

To unsubscribe from this discussion, e-mail: [[email protected]].
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.