Can we get rid of the hash(password) dance?

[William Reade]

Just to add to what already seems to be consensus: yes, the mongodb
password dance is redundant and should be dropped. The API password dance
remains important, but is not implicated here.

Cheers
Willliam


On Thu, Jul 17, 2014 at 11:01 AM, John Meinel <john at arbash-meinel.com>
wrote:

> ...
>
>
>> From what I can tell poking around the code base, the only place that
>>> still uses the hash(password) is actually in the Dummy provider.
>>>
>>>
>> Right, and when I remove that code all the tests pass with some session
>> copying in place!
>>
>> https://github.com/voidspace/juju/compare/master...copy-sessions
>>
>>
>>  I feel like we're at a point where we can safely remove that from the
>>> Dummy provider, and also remove the fallback code in our 'connect to the
>>> database' code. (If we leave it in, then I think after
>>>
>> Do you mean the "oldPassword" logic in cmd/jujud/agent.go (I had to add
>> code there to re-open the state when we change the password.)
>>
>
> What I mean is removing the "if IsUnauthorized(err) { altpassword =
> hash(password); login(alt password); SetPassword(password) }"
> Because *if* the current access is actually hash(password) we still (?)
> need to set it to the real password. (and then reconnect).
>
> I'd be ok removing the fallback, as I don't think there will be any real
> sites out there that need it in production. Those that might have would
> have already run the fallback code.
>
> John
> =:->
>
>
>> All the best,
>>
>> Michael
>>
>>
>>  changing the password just reconnecting to the database is fine, because
>>> it should happen infrequently.
>>>
>>> Thoughts?
>>>
>>> John
>>> =:->
>>>
>>>
>>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140718/5de3bac6/attachment.html>