Project

General

Profile

Actions

Defect #5236

open

Can't browse SVN of private project w/o giving a login and pass in settings

Added by Anthony Paul about 14 years ago. Updated almost 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
SCM
Target version:
-
Start date:
2010-04-02
Due date:
% Done:

0%

Estimated time:
Resolution:
Affected version:

Description

Hi,

After many testings, it seems one can't browse the repository of a private project if no login/password have been set in the Settings/Repository tab of that project. (and so, even if the user currently logged on Redmine is Manager of that project).

The login/password of that tab is stored in plain text in the repositories table.
I think it could be interesting if Redmine.pm gives access on all repositories to the Redmine host then check if the logged user is part of the project requested (maybe we just need to check if the current user is part of members, and then maybe no need to store the password)

Actually, I don't know if it is a bug or if I should request a new feature.

I posted more details in the forum: [Patch?] Browse private repositories without supplying lo...


Files

Redmine.pm.patch (1.1 KB) Redmine.pm.patch Anthony Paul, 2010-04-06 17:54
subversion_adapter.rb.patch (1.57 KB) subversion_adapter.rb.patch Anthony Paul, 2010-04-06 17:54

Related issues

Has duplicate Redmine - Defect #11343: I'm solved svn connect https protoclClosed

Actions
Actions #1

Updated by Anthony Paul about 14 years ago

Here is a small patch for what I'm trying to do.
First of all, my apologies, I'm not a hacker... (and I'm not able to move the "defect" status to "patch" status.

First, I change Redmine.pm so we can go through authentication when the svn client has the same IP as the server. In many cases, it should mean that Redmine is trying to access to the SVN repository.

Then I modified subversion_adapter.rb so when Redmine is trying to display a private repository it checks if the current user is a member of this project.

It's obviously less safe. Please let me know if you have any suggestions.

Actions #2

Updated by Radek Antoniuk about 14 years ago

Nice patch, although imho it is totally the wrong way to go.
Firstly, you don't have to change Redmine.pm because you can achieve the same via
order allow,deny
allow from 127.0.0.1

Satisfy Any
in your apache webdav conf of subversion server.

Actions #3

Updated by Anthony Paul about 14 years ago

Hi and thank you for your comment!
As you can see in my post via the forum ( http://www.redmine.org/boards/2/topics/12645 ), I tried this configuration:

Allow from 127.0.0.1 11.22.33.44 myserver.mydomain.fr ...
satisfy any
but I was unsuccessful...
From my server prompt, an "svn list https://myserver.mydomain.fr/svn/myproject" was still asking me for login and password. That's why I patched Redmine.pm. However, maybe I missed something so I'll try again with a genuine Redmine.pm.

Actions #4

Updated by Radek Antoniuk about 14 years ago

order allow,deny
or
order deny,allow
deny from all
allow from 127.0.0.1
allow from myserver.mydomain.fr

satisfy any

has to work.

Actions #5

Updated by Anthony Paul about 14 years ago

Thank you for your help!
I tried alternative order since I used order allow,deny before, but I still have the same result... Redmine's log is complaining about
"No close tag for /lists/list" as before, and when I try:

root@myserver# svn list https://myserver.mydomain.fr/svn/project --non-interactive --trust-server-cert

I still get
Could not authenticate to server: rejected Basic challenge (https://myserver.mydomain.fr)

Maybe I'm really missing something obvious, but I can't find it out...
(Just to be sure, here is my modified conf:)

PerlLoadModule Apache::Redmine
PerlLoadModule Authen::Simple::LDAP
<Location /svn>
        DAV svn
        SVNParentPath "/var/svn" 
        Satisfy any
        PerlAccessHandler Apache::Authn::Redmine::access_handler
        PerlAccessHandler Apache::Authn::Redmine::authen_handler
        AuthType Basic
        AuthName "SVN Repository" 
        AuthBasicAuthoritative off

        <Limit GET PROPFIND OPTIONS REPORT>
                Require valid-user
                Order deny,allow
                Deny from all
                Allow from 127.0.0.1
                Allow from 11.22.33.44
                Allow from myserver.mydomain.fr
                Satisfy any
        </Limit>
        <LimitExcept GET PROPFIND OPTIONS REPORT>
                Require valid-user
        </LimitExcept>
        RedmineDSN "DBI:mysql:database=redmine_db;host=localhost" 
        RedmineDbUser "dbuser" 
        RedmineDbPass "dbpass" 
</Location>

Thanks for your help..

Actions #6

Updated by Radek Antoniuk about 14 years ago

obviously.
you are using https. probably with a self-signed certificate.
so, you have to add the certificate to the trusted ones.

Please see
http://www.redmine.org/boards/2/topics/11896
this will help you.

Actions #7

Updated by Anthony Paul about 14 years ago

Yes, I'm using a self-signed certificate however it doesn't seem to be the problem.
I've read many topics about it, and tried both options "--trust-server-cert" and "--config-dir" with a well .subversion directory created for my www-data user (as you can see in my forum post). Anyway, since I'm using now svn > 1.6, I think option "--trust-server-cert" should be sufficient.

More, if I disable SSL so I can join Redmine and SVN repositories through HTTP only, I still have this problem.

I thought my <Limit> directive wasn't read by Apache for any reason, but with further testing, I can confirm it is understood (ie: if I write a "deny from all" in this, everything is denied as expected).
Apache doc refers that the REPORT method isn't managed by <Limit>, I removed it with no more success.

I don't remember if I mentioned it before, but in case of a "public" project, everything work as expected. My problem occurs only for "private" project.
As soon as I make my project "private", an "svn list http://myserver.mydomain.fr/svn/private_project" from my server prompt asks me for password...

If you have the opportunity, could you try it with a private project on your own configuration if you still use SVN and HTTP?

Thanks for your help again!

Actions #8

Updated by Radek Antoniuk about 14 years ago

All my projects are private.
And I don't see any connection between setting the project to private and the ability to invoke a shell command svn list (for example) without a password.

My advice, go to apache logs, and check what IP is trying to access the repository
and then allow from that ip.
You can also test
allow from any

if it works

Actions #9

Updated by Anthony Paul about 14 years ago

Thanks for your prompt reply!

Allow from any (or all) didn't change the behaviour.
Checking the log let me know that the server is queried with its own address (configured IP as 11.22.33.44 not 127.0.0.1) and thus I added it in the "Allow from" list. Additionaly, because I wasn't sure the svn client used this address, I checked it with tcpdump and it appears it also uses 11.22.33.44.

Because of the apache config:

<Location /svn>
        ...
        <Limit GET PROPFIND OPTIONS>
                Order allow,deny
                Allow from 127.0.0.1
                Allow from 11.22.33.44
                Allow from all
                Satisfy any
                Require valid-user
        </Limit>
        ...

I guess using an svn client from 11.22.33.44 prompt should act like this:
if @IP == 11.22.33.44 then "allow access"
else "ask for a password"

That's what the subversion_adapter.rb does to get the xml output (actually, with more options like "svn info https://... --non-interactive --xml").
Using this command line is more convenient for testing than refresh the redmine page on the "The entry or revision was not found in the repository" message and get not so pertinent informations in the log.

By the way, my log are always the same,
Redmine:

Processing RepositoriesController#show (for 10.xx.xx.xx at 2010-04-09 10:35:53) [GET]
  Parameters: {"action"=>"show", "id"=>"adminscript", "controller"=>"repositories"}
Error parsing svn output: #<REXML::ParseException: No close tag for /lists/list>
/usr/lib/ruby/1.8/rexml/parsers/treeparser.rb:28:in `parse'
... snip ...
/usr/lib/phusion_passenger/passenger-spawn-server:61
...
No close tag for /lists/list
Line: 
Position: 
Last 80 unconsumed characters:
Output was:
 <?xml version="1.0"?>
<lists>
<list
   path="https://myserver.mydomain.fr/svn/private_project">
Rendering template within layouts/base
Completed in 2376ms (View: 233, DB: 20) | 500 Internal Server Error [https://myserver.mydomain.fr/projects/private_project/repository]

And Apache:

svn: OPTIONS of 'https://myserver.mydomain.fr/svn/private_project': authorization failed: Could not authenticate to server: rejected Basic challenge (https://myserver.mydomain.fr)

(one more thing, I don't provide login/password in the settings / repository tab since that's what I want to avoid)

Actions #10

Updated by Radek Antoniuk about 14 years ago

Move the things out of <Limit>, to the <Location> and try then?

Actions #11

Updated by Anthony Paul about 14 years ago

Hi again,

Yeah, I had the same idea (and I'm confused I didn't think about it before).
I moved the <limit> so I have:

<Location /svn>
        DAV svn
        SVNParentPath "/var/svn" 

        PerlAccessHandler Apache::Authn::Redmine::access_handler
        PerlAccessHandler Apache::Authn::Redmine::authen_handler
        AuthType Basic
        AuthName "SVN Repository" 
        AuthBasicAuthoritative off

        # Allow from all

        Order allow,deny
        Allow from 127.0.0.1
        Allow from 10.x.x.x
        Allow from myserver.mydomain.fr
        Satisfy any
        Require valid-user

#       <LimitExcept GET PROPFIND OPTIONS REPORT>
#               Require valid-user
#       </LimitExcept>

        RedmineDSN "DBI:mysql:database=redmine_db;host=localhost" 
        RedmineDbUser "..." 
        RedmineDbPass "..." 
</Location>

I have the same result: Redmine still can't browse the repository, the server prompt still asks for password, but svn on a client keeps on working as expected.
Comment the LimitExcept doesn't change the behaviour as well.
Same messages in the logs.
Of course, I had to comment out the "Allow from all" to be able to checkout or commit from a remote client.

And as I said in the forum, I can't remove the "require valid-user" because I would have this message in Redmine error log:
[error] access to /svn/sandbox failed for 11.22.33.44, reason: No authentication has been configured
(it's a message from Redmine.pm)

Actions #12

Updated by Radek Antoniuk about 14 years ago

Interesting. Can you try hashing out the PerlAccessHandler too?

Actions #13

Updated by Anthony Paul about 14 years ago

Radek Antoniuk wrote:

Interesting. Can you try hashing out the PerlAccessHandler too?

hmmm... I'm not sure to know how to do this, sorry, I'm not a hacker and my Perl skills are not so high...
However, the result of this line:
my ($res, $redmine_pass) = $r->get_basic_auth_pw();

Give me a "401" in $res. It should mean "auth required".

Do you know how I could get more (interesting) infos?
Thanks for your help again and again!

Actions #14

Updated by Radek Antoniuk about 14 years ago

I meant...
comment out those two lines in <Location> :)

Actions #15

Updated by Anthony Paul about 14 years ago

aaaaaah, sorry..!
OK, I've commented them out, and well seen, it still asks me for a password at the server prompt and still doesn't display the repository from redmine.
However, what I tried is with a config conform with this howto: http://www.redmine.org/wiki/redmine/Repositories_access_control_with_apache_mod_dav_svn_and_mod_perl

<Location /svn>
        DAV svn
        SVNParentPath "/var/svn" 
        Satisfy any

#       PerlAccessHandler Apache::Authn::Redmine::access_handler
#       PerlAccessHandler Apache::Authn::Redmine::authen_handler
        AuthType Basic
        AuthName "SVN Repository" 

        Order deny,allow
(1)     Deny from all

        <Limit GET PROPFIND OPTIONS REPORT>
                Order allow,deny
                Allow from 127.0.0.1
                Allow from 11.22.33.44
                Satisfy any
                Require valid-user
        </Limit>
        <LimitExcept GET PROPFIND OPTIONS REPORT>
                Require valid-user
        </LimitExcept>

        database stuff...

At (1), if I change to a "Allow from all", then everything works as it should:
- svn doesn't prompt for a password when launched from the server
- redmine displays the repos
- remote client have to supply their password (though these passwords are not recognized because we commented out the perl module)

I don't understand why the "deny from all" in <location> is not overriden by the "allow from my.ip" in <limit>...

Actions #16

Updated by Anthony Paul about 14 years ago

oooops, sorry...
if I use the "allow from all" in <location>, then nobody is asked password to co/ci (both server or remote client),
but if I use "deny from all", everybody is asked.
sorry...

Actions #17

Updated by Anthony Paul about 14 years ago

sorry again for multi-posting...
If I remove any "Allow from..." from <location>, it seems to work. ie:
no password asked from server prompt,
no password asked from client if it is a public project
password asked from client if it is private project.

However, as soon as I put back the perl handler in the conf, server starts to ask me password for private project, and more, password provided from client is not recognized which gives only this in the logs:
- anthony [09/Apr/2010:17:39:25 +0200] "OPTIONS /svn/sandbox HTTP/1.1" 500 756 "-" "SVN/1.6.5 (r38866) neon/0.28.6" )
I have to add "allow from all" in <location> in order the client password is correctly recognized...

I'm turning crazy...

The best I can do is to let this <location>Allow from all, then use my Redmine.pm patch (I forgot to write it in the main post, but this patch works only if this <location>Allow from all is set)

Actions #18

Updated by Radek Antoniuk about 14 years ago

Hey,

I've just configured my instance of Redmine to use
http://www.redmine.org/wiki/redmine/Repositories_access_control_with_apache_mod_dav_svn_and_mod_perl
and with
allow from my.ip.of.redmine
satisfy any

and it works perfectly fine.

Actions #19

Updated by Anthony Paul almost 14 years ago

Thank you so much for having done those tests.
I also tried different config without success. Maybe the problem is because I use the redmine package on debian testing, though I tried with the redmine source tarball as well. The problem should come from my eyes... I'll try it again later...

Actions #20

Updated by Felix Schäfer almost 14 years ago

Can this be considered close as it is already handled in the docs by the additional "allow from IP" setting?

Actions #21

Updated by Anthony Paul over 13 years ago

Actually, I still have the problem and have to use the patches I attached above... Maybe it's a debian testing issue since I can't figure out why I can't make it works with an "allow from ip"...

Actions #22

Updated by Felix Schäfer over 13 years ago

Anthony Paul wrote:

Actually, I still have the problem and have to use the patches I attached above... Maybe it's a debian testing issue since I can't figure out why I can't make it works with an "allow from ip"…

The "allow from IP" setting is an apache setting and should make apache completely bypass any other authentication scheme defined in that portion of the apache config, so nothing that has to do with redmine here.

Actions #23

Updated by Mr Embedded over 11 years ago

I had this same problem where I was forced to add a username/password with https no matter if I:

  • Accepted the certificate initially and used --config-dir
  • Used --trust-server-cert

If I removed the 'Deny from All' like you did from the <location> tag it did work with no security.

My issue was in the /etc/host file. The apache logs were showing the hostname (not localhost or IP) was being used in the call. I had localhost, 127.0.0.1 and the fqdn as 'allow from' items but I needed to add the fqdn inside the /etc/hosts file and reference it to the local IP for this to work properly.

This was probably due to some funkyness with 1:1 NAT and some NAT reflection settings in use.

Actions #24

Updated by Toshi MARUYAMA almost 7 years ago

  • Description updated (diff)
Actions #25

Updated by Toshi MARUYAMA almost 7 years ago

  • Has duplicate Defect #11343: I'm solved svn connect https protocl added
Actions

Also available in: Atom PDF