Jason Reusch wrote:
I need to clean things up a bit before publishing the code, but it works.
Typical AGPL warning: you need to make the code available to the users
of the program, regardless of how clean it is.
My motivation is to integrate authentication with an existing MS
Active Directory domain. I know "." generally falls into the
potentially problematic character category, but... the user names in
the domain are in first.last format. Is there a reason a dot must
absolutely be excluded from laconica nicknames? A URL encoding
nightmare perhaps?
No, I don't think it'd be a big deal. The only things that come to mind
offhand are these: that Unix systems typically treat files with names
like '.something' as hidden, so a file in the /foo/ directory on a Web
server named '.bar' wouldn't be accessible from the Web. Similarly, some
systems (DOS-like only?) treat 'file.' and 'file' as identical.
All of which only matters that much if the Web server expects to be tied
to a file system, and checks for that. (I had some problems with this
with page names in Wikitravel, is why I'm thinking of it.)
Oh, and I think Twitter only allows alphanum and _, so there's a little
impedance mismatch waiting to happen, too.
The hard part now would be finding all the places that we check
usernames, and add '.' as an allowable character. If we/you are going to
do that, it'd probably be worthwhile to add in '-' and '_' while we're
at it.
A few questions:
1. How are you storing profile data? Is it in the LDAP server, too?
2. I'd like to make an AuthenticationEngine abstract class so we
could have different login systems: other Web programs (like
MediaWiki or Drupal), LDAP, /etc/passwd, etc.
3. I think the AuthenticationEngine should probably be orthogonal to
the ProfileEngine (where profile data is stored). Some systems
might be able to store some or all of our profile elements (full
name, avatar, homepage, location, bio), others might not at all.
Anyways, looking forward to seeing your code. There have been rumblings
about providing this functionality, but no code has been forthcoming so far.
-Evan
_______________________________________________
Laconica-dev mailing list
[email protected]
http://mail.laconi.ca/mailman/listinfo/laconica-dev
