[TurboGears] Re: IdentityProvider plugins
No, but it would be really easy to do with a CompositeIdentityProvider that calls identity_from_request for each other provider until it gets an identity.On 7 Jan, 2006, at 4:37 pm, nerkles wrote:Any plans for multiple providers? For example it tries LDAP, and ifthat doesn't work, then it tries SQLObject?Glad to see this opening up though. :D --Jeff Watkinshttp://newburyportion.com/Getting an education was a bit like a communicable sexual disease. It made you unsuitable for a lot of jobs and then you had the urge to pass it on. -- (Terry Pratchett, Hogfather)
[TurboGears] Re: IdentityProvider plugins
Composition via inheritance is one way. Another way could be middleware pipelining a-la-Paste. This would allow arbitrary composition of many single-purpose IdentityProvider, to KISS. Alas I lack experience on the subject... Jeff Watkins wrote: No, but it would be really easy to do with a CompositeIdentityProvider that calls identity_from_request for each other provider until it gets an identity. On 7 Jan, 2006, at 4:37 pm, nerkles wrote: Any plans for multiple providers? For example it tries LDAP, and if that doesn't work, then it tries SQLObject? Glad to see this opening up though. :D -- Jeff Watkins http://newburyportion.com/ Getting an education was a bit like a communicable sexual disease. It made you unsuitable for a lot of jobs and then you had the urge to pass it on. -- (Terry Pratchett, _Hogfather_) signature.asc Description: OpenPGP digital signature
[TurboGears] Re: IdentityProvider plugins
nerkles [EMAIL PROTECTED] writes: Any plans for multiple providers? For example it tries LDAP, and if that doesn't work, then it tries SQLObject? It would be easily achievable with PAM... ;-) A plugin for PAM would enable a series of authentication methods -- fingerprint, retin scan, shadow passwords, passphrases, OTP, clear text passwords, no passwords at all... -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: IdentityProvider plugins
I've already modified my in-house SQLObject provider to have greater control over the names of fields - I.e. if you want to use EMail as the userId... Also changed was the default encryption behavior, which includes a rot13 tester, and encryption aliases (sha1 vs. sha, etc.). def rot13(text): table = string.maketrans( 'nopqrstuvwxyzabcdefghijklmNOPQRSTUVWXYZABCDEFGHIJKLM', 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ') return string.translate(text, table) algorithm= get(identity.soprovider.password_encryption, md5) if algorithm == md5: self.encrypt_password = lambda pw: md5.new(pw).hexdigest() elif algorithm in (sha1, sha): self.encrypt_password = lambda pw: sha.new(pw).hexdigest() elif algorithm in (plain, none, None): self.encrypt_password = lambda pw: pw elif algorithm in (rot13, caesar): self.encrypt_password = lambda pw: rot13(pw) else: raise identity.IdentityConfigurationException(Unknown password encryption algorithm: %s % algorithm) I'll finish it up today and post it up under several new tickets.
[TurboGears] Re: IdentityProvider plugins
Matthew Bevan, el s�bado 7 de enero a las 16:53 me escribiste: Also changed was the default encryption behavior, which includes a rot13 tester, and encryption aliases (sha1 vs. sha, etc.). I don't think adding aliases is a good thing (in this case). Is too simple to make it complex, what if tomorrow is there a sha2 algorithm and someone use just sha? It could be confusing and is harder to maintain and document and there is no real gain in adding aliases IMHO... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ., \ GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05 / '' Si por el chancho fuera, se autocomería con chimichurri Worshestershire!
