Question on SVN materialisation when svn+ssh (and subclipse) [message #21255] |
Wed, 16 July 2008 08:47 |
Adrian Skehill Messages: 55 Registered: July 2009 |
Member |
|
|
Hi There,
Until a few days ago I had a good reliable automated build system
running using Buckminster. For the moment my code is only accessible via
svn+ssh plus username and password. But I had inadvertently configured
my subversion authentication so I didn't have to use a username and
password in the URL's placed in the RMAP. My VPS system got attacked and
I realised I needed to tighten up security, changed the password to my
build administrator account and then things started to go wrong on me.
Buckminster just refused to resolve the code from that point on. After
lots of googling I was unable to re-create the stuff in the auth
directory to provide under the covers svn configuration, so I thought
I'd see what was going wrong with Buckminster.
I took a look at the code.
In org.eclipse.buckminster.subclipse.internal.SvnSession a subclass of
ISVNPromptUserPassword is created which allows the SVN client to get
authentication information for the request. As is, I was able to get
things to work if, I put the username and password in the URL *and*
modified the promptSSH() method to return true. Grand, materialisation
succeeded.
But I don't want to have the password in the URL. Removed it, but then
ran into problems as Buckminster relies on *both* password and username
to be present in the URL before it will register the PasswordPrompt
class (see SvnSession:572 & 728).
Subversive is similar in logic, however, if the password is specified in
the URL, it works without code modification as the password prompting
logic is different.
So before I jump in with both feet into the code is there a particular
reason for this logic? Ideally what I'd like to do is define the
username in the url, but then use a key at runtime rather than having to
supply the password.
And one last thing, Buckminster now swallows exceptions on me and
finding these problems is becoming very difficult. I run with loglevel
of DEBUG but the only way I was able to see the exception with the
actual cause of the problem was in the debugger. Is there a command line
arg to get even more verbose info out?
Many thanks,
Adrian.
|
|
|
Re: Question on SVN materialisation when svn+ssh (and subclipse) [message #21273 is a reply to message #21255] |
Wed, 16 July 2008 09:55 |
|
Hi Adrian,
There's no reason other then perhaps ignorance for the current
user-name/password design for the SVN providers and your improvements
sounds reasonable to me.
Ideally, the SVN provider should be able to connect when:
1. No username/password specified in case a matching repository has been
declared in the workspace already (with associated credentials) or when
anonymous access is granted.
2. Both username/password are specified in the URL.
3. Only username specified in the URL in combination with a key.
Buckminster should normally not swallow exceptions. The behavior we are
trying to incourage is to print the exception message as an ERROR and to
display the stack-trace of the exception if the log-level is set to
DEBUG. If we have exceptions that do not behave that way then that's to
be considered a bug. Hiding exceptions is generally a bad thing.
Regards,
Thomas Hallgren
Adrian Skehill wrote:
> Hi There,
>
> Until a few days ago I had a good reliable automated build system
> running using Buckminster. For the moment my code is only accessible via
> svn+ssh plus username and password. But I had inadvertently configured
> my subversion authentication so I didn't have to use a username and
> password in the URL's placed in the RMAP. My VPS system got attacked and
> I realised I needed to tighten up security, changed the password to my
> build administrator account and then things started to go wrong on me.
> Buckminster just refused to resolve the code from that point on. After
> lots of googling I was unable to re-create the stuff in the auth
> directory to provide under the covers svn configuration, so I thought
> I'd see what was going wrong with Buckminster.
>
> I took a look at the code.
>
> In org.eclipse.buckminster.subclipse.internal.SvnSession a subclass of
> ISVNPromptUserPassword is created which allows the SVN client to get
> authentication information for the request. As is, I was able to get
> things to work if, I put the username and password in the URL *and*
> modified the promptSSH() method to return true. Grand, materialisation
> succeeded.
>
> But I don't want to have the password in the URL. Removed it, but then
> ran into problems as Buckminster relies on *both* password and username
> to be present in the URL before it will register the PasswordPrompt
> class (see SvnSession:572 & 728).
>
> Subversive is similar in logic, however, if the password is specified in
> the URL, it works without code modification as the password prompting
> logic is different.
>
> So before I jump in with both feet into the code is there a particular
> reason for this logic? Ideally what I'd like to do is define the
> username in the url, but then use a key at runtime rather than having to
> supply the password.
>
> And one last thing, Buckminster now swallows exceptions on me and
> finding these problems is becoming very difficult. I run with loglevel
> of DEBUG but the only way I was able to see the exception with the
> actual cause of the problem was in the debugger. Is there a command line
> arg to get even more verbose info out?
>
> Many thanks,
> Adrian.
|
|
|
|
Powered by
FUDForum. Page generated in 0.02627 seconds