And maybe it could be reclassified as a solution 2) rather than a
workaround c)


2013/7/9 Nicolas Cellier <[email protected]>

> c) store some hash of the password (MD5 or something)?
>
> The question is why do you want to store such information?
>
>
> 2013/7/9 Mariano Martinez Peck <[email protected]>
>
>> Wow...after a couple of hours chasing a problem in my app, I faced a
>> problem with Glorp's Login. I was using a ConnectionPool that uses a
>> Dictionary to store Login. Each kay is a login instance and the value is an
>> instance of a connection pool.
>>
>> But I was getting multiple instances (entries in the dictionary and pool
>> instances). The problem is Login >>#=
>>
>> = aLogin
>> self halt.
>>  ^self class == aLogin class and:
>> [self name = aLogin name and:
>> [self database class = aLogin database class and:
>>  [self username = aLogin username and:
>> [self password = aLogin password
>> and: [self connectString = aLogin connectString]]]]]
>>
>> Because it expects the passwords to be equal, while Login can be "secure"
>> and hence, the password is nil after the login. So what happened here is
>> that my Login were secure (by default you have that behavior) and hence,
>> two Login that were created exactly with the same data will give you false
>> once on of them is logged.
>>
>> Solutions?
>>
>> 1) Ignore the password check when using secure connections?
>>
>> Workarounds?
>>
>> a) In my app I can try to store somewhere the Login instance and always
>> reuse it.
>> But I am not sure if this could work...because I will have multiple
>> PharoDatabaseAccessors pointing to the same Login instance...
>>
>> b) send a secure: false  to my Login instances....
>>
>> Of course I would try to avoid having to do b).
>>
>> Any ideas?
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>

Reply via email to