Authorization issues with SCPlugin 0.6?

[Joshua Hadley]

I'm having trouble with the new SCPlugin v0.6. I get "OPTIONS of '/
path/to/repos/dir': authorization failed (http://myserver.com)" when  
I attempt to commit, and similarly "PROPFIND of '/path/to/repos/dir':  
authorization failed (http://myserver.com)" when I try to check out.  
I have to guess that pretty much any other interaction with the  
server will also fail, but I have not done a thorough investigation.

Per the instructions, I removed the old SCPlugin files, logged out  
and back in, I have svn 1.4 CLI installed, and have initiated a  
checkout from the server in question with the CLI before using SCPlugin.

Any ideas? r396 works fine.


Josh



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Stephen F. Steiner]

On Jan 27, 2007, at 1:07 PM, Joshua Hadley wrote:

> I'm having trouble with the new SCPlugin v0.6. I get "OPTIONS of '/
> path/to/repos/dir': authorization failed (http://myserver.com)"  
> when I attempt to commit, and similarly "PROPFIND of '/path/to/
> repos/dir': authorization failed (http://myserver.com)" when I try  
> to check out. I have to guess that pretty much any other  
> interaction with the server will also fail, but I have not done a  
> thorough investigation.
>
> Per the instructions, I removed the old SCPlugin files, logged out  
> and back in, I have svn 1.4 CLI installed, and have initiated a  
> checkout from the server in question with the CLI before using  
> SCPlugin.

I was having the same problem and it turned out I had a  1.3 client  
in the path that was getting picked up somehow.  I just did an `svn --
version` to confirm then a `which svn` to find it.

I reinstalled 1.4x from one of the bundles mentioned on the site and  
that problem went away.

Now I can do a status and it shows the correct revision but no info  
about changed etc. files.

S

Stephen F. Steiner
Integrated Development Corporation
ssteiner@...
www.integrateddevcorp.com
[phone]





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jrep]

On Jan 27, 2007, at 10:07 AM, Joshua Hadley wrote:

> I'm having trouble with the new SCPlugin v0.6. I get "OPTIONS of '/
> path/to/repos/dir': authorization failed (http://myserver.com)"  
> when I attempt to commit, and similarly "PROPFIND of '/path/to/
> repos/dir': authorization failed (http://myserver.com)" when I try  
> to check out. I have to guess that pretty much any other  
> interaction with the server will also fail, but I have not done a  
> thorough investigation.
>
> Per the instructions, I removed the old SCPlugin files, logged out  
> and back in, I have svn 1.4 CLI installed, and have initiated a  
> checkout from the server in question with the CLI before using  
> SCPlugin.
>
> Any ideas? r396 works fine.

Between r396 and v0.6, there was one change which is related: we now  
use the Mac OS X Keychain to store credentials (r399 on the universal-
test branch; r404 on trunk).  So does svn 1.4 CLI, unless you prevent  
that (with ~/.subversion/config: store-auth-creds = no).  But I guess  
there's one subtlety we didn't really document, maybe this is your  
problem?

When we say "you have to connect to the repository one time using the  
CLI," we actually mean "with the v1.4 CLI."  If you've only connected  
to this particular repository with your older 1.3 CLI, then that  
doesn't count, SCPlugin will still not find the credentials in the  
Keychain.

Another thought: when you say "r396 works," do you mean an r396 you  
built from trunk, or from the universal-test branch?  The trunk  
version would, I believe, only work with Subversion v1.3 (and  
likewise, would store credentials in your home directory, not the  
Keychain, since even Subversion didn't learn the Keychain trick until  
v1.4).

Are there any complaints in console.log during these failures-to-
authorize?

>
>
> Josh
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

-==-
Jack Repenning
Director, Software Product Architecture
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: [phone]
raindance: 844.7461
aim: jackrepenning
skype: jrepenning




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Joshua Hadley]

I got it working by removing the files inside of ~/.subversion/auth/
svn.simple/, then doing a new checkout with the CLI. The v0.6 plugin  
now works as expected.


Josh



On Jan 29, 2007, at 10:26 AM, Jack Repenning wrote:

> On Jan 27, 2007, at 10:07 AM, Joshua Hadley wrote:
>
>> I'm having trouble with the new SCPlugin v0.6. I get "OPTIONS of '/
>> path/to/repos/dir': authorization failed (http://myserver.com)"  
>> when I attempt to commit, and similarly "PROPFIND of '/path/to/
>> repos/dir': authorization failed (http://myserver.com)" when I try  
>> to check out. I have to guess that pretty much any other  
>> interaction with the server will also fail, but I have not done a  
>> thorough investigation.
>>
>> Per the instructions, I removed the old SCPlugin files, logged out  
>> and back in, I have svn 1.4 CLI installed, and have initiated a  
>> checkout from the server in question with the CLI before using  
>> SCPlugin.
>>
>> Any ideas? r396 works fine.
>
> Between r396 and v0.6, there was one change which is related: we  
> now use the Mac OS X Keychain to store credentials (r399 on the  
> universal-test branch; r404 on trunk).  So does svn 1.4 CLI, unless  
> you prevent that (with ~/.subversion/config: store-auth-creds =  
> no).  But I guess there's one subtlety we didn't really document,  
> maybe this is your problem?
>
> When we say "you have to connect to the repository one time using  
> the CLI," we actually mean "with the v1.4 CLI."  If you've only  
> connected to this particular repository with your older 1.3 CLI,  
> then that doesn't count, SCPlugin will still not find the  
> credentials in the Keychain.
>
> Another thought: when you say "r396 works," do you mean an r396 you  
> built from trunk, or from the universal-test branch?  The trunk  
> version would, I believe, only work with Subversion v1.3 (and  
> likewise, would store credentials in your home directory, not the  
> Keychain, since even Subversion didn't learn the Keychain trick  
> until v1.4).
>
> Are there any complaints in console.log during these failures-to-
> authorize?
>
>
>
>
>
>>
>>
>> Josh
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> -==-
> Jack Repenning
> Director, Software Product Architecture
> CollabNet, Inc.
> 8000 Marina Boulevard, Suite 600
> Brisbane, California 94005
> office: +1 650.228.2562
> mobile: [phone]
> raindance: 844.7461
> aim: jackrepenning
> skype: jrepenning
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jrep]

On Jan 29, 2007, at 10:46 AM, Joshua Hadley wrote:

> I got it working by removing the files inside of ~/.subversion/auth/
> svn.simple/, then doing a new checkout with the CLI. The v0.6  
> plugin now works as expected.

Thaaaaaat's interesting ... I do not recall that the Subversion code  
works that way ... lemme check with Team Subversion to get the  
straight scoop, and then see about updating our dox.

-==-
Jack Repenning
Director, Software Product Architecture
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: [phone]
raindance: 844.7461
aim: jackrepenning
skype: jrepenning




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jrep]

On Jan 29, 2007, at 10:46 AM, Joshua Hadley wrote:

> I got it working by removing the files inside of ~/.subversion/auth/
> svn.simple/, then doing a new checkout with the CLI. The v0.6  
> plugin now works as expected.

Ack!  It's true, it's true!  I find this very tangential remark in  
the dev@subversion list

>> unless someone cleans out all the unencrypted auth data, we're not  
>> more
>> secure than 1.0.

... which it seems to me really ought to be more prominent than that!

-==-
Jack Repenning
Director, Software Product Architecture
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: [phone]
raindance: 844.7461
aim: jackrepenning
skype: jrepenning




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Joshua Hadley]

Yeah, I guess those would've been in there from my previous svn (1.3)  
installation. Apparently the 1.4 installation does not remove them  
(nor even warn about it). I kind of wondered why I wasn't getting  
asked for auth when I did the checkout with svn 1.4...it was simply  
using the existing unencrypted auth files.

Sounds to me like this is something an svn Mac installer could/should  
handle. But as a backup, perhaps the planned SCPlugin installer could  
be set up to look for and (optionally?) remove these files, too?


Josh



On Jan 29, 2007, at 11:37 AM, Jack Repenning wrote:

> On Jan 29, 2007, at 10:46 AM, Joshua Hadley wrote:
>
>> I got it working by removing the files inside of ~/.subversion/
>> auth/svn.simple/, then doing a new checkout with the CLI. The v0.6  
>> plugin now works as expected.
>
> Ack!  It's true, it's true!  I find this very tangential remark in  
> the dev@subversion list
>
>>> unless someone cleans out all the unencrypted auth data, we're  
>>> not more
>>> secure than 1.0.
>
> ... which it seems to me really ought to be more prominent than that!

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jrep]

On Jan 29, 2007, at 11:46 AM, Joshua Hadley wrote:

> Sounds to me like this is something an svn Mac installer could/
> should handle. But as a backup, perhaps the planned SCPlugin  
> installer could be set up to look for and (optionally?) remove  
> these files, too?

Yes, I had that same thought.  But I need to mull it over a bit more  
to decide what I think about it.  The base case is obvious enough,  
but even so it means someone will be prompted for a password (I  
imagine the poor sod who hasn't typed a password in so long he's  
forgotten it...).  Also, there can be several subdirectories of  
auth/, I'm not certain that svn.simple is the only one affected by  
this change.

And there's the layering problem (to which you allude): to the extent  
this non-clearing-out-of-passwords may be viewed as a bug, surely  
it's a Subversion bug; it would be better if we contributed the fix  
to core Subversion.  Only of course, there's no MacOS installer in  
the core project.

What really OUGHT to happen, seems to me, is that Subversion itself  
migrates the credentials into the Keychain at the first 1.4 access,  
injecting the creds and removing the old svn.simmple/* file  
(actually, it doesn't get removed; the public info like the URL and  
user name remain there, but anyway "cleaning up the old file").

Flipped around: are we violating the protocol here?  Ought we,  
perhaps, to look into the old-style cache first, and go to the new  
one only if that fails?  We should confirm what the CLI actually does  
about this....

-==-
Jack Repenning
Director, Software Product Architecture
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: [phone]
raindance: 844.7461
aim: jackrepenning
skype: jrepenning




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...