Indeed. Workaround c) Use database name or connectionString as key rather than the Login instance :) On Tue, Jul 9, 2013 at 5:48 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
And maybe it could be reclassified as a solution 2) rather than a workaround c)
2013/7/9 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
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 <marianopeck@gmail.com>
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
-- Mariano http://marianopeck.wordpress.com