[geeklog-devel] Re: A&A AEPasswordGenerator.class.php
tony at tonybibbs.com
Tue Jun 22 13:51:27 EDT 2004
On Tue, 2004-06-22 at 10:31, Vincent Furia wrote:
> I rewrote the password generator/validator using regex to give much
> more flexibility when it comes to creating rules (see attached).
> Since the generator is creating a random password (can really only be
> broken brute force) from a decent sized set of characters I didn't
> think enforcing any rules is really necessary. Especially since A&A
> should probably force a password change after a password reset upon
> first login...
Enforcing password rules is more important when the user changes their
own password. If you look at the changePassword() and
changePasswordByAdmin() on the AEPearDBProvider you'll notice we verify
the strength of the password against our configured rules. If you can
at least agree to that much, I don't think it is a stretch to say we may
as well enforce the rules on passwords generated by our system.
Use of regex is fine, I personally don't like it because it is hard to
read and this code probably won't get hammered too much but the
performance gain is duly noted and I'm flexible.
> Also, I thought I'd suggest password reset support like Dirk has place
> into the most recent version of Geeklog. i.e. you send a link that
> includes a big random value (hash of some kind) and make the user
> change their password when following the link. The is easy to
> implement with a built in Auth system, not sure how you would do this
> (or force a password change) with A&A... Catch me on IRC sometime and
> we can talk more about it...
The hard part is deciding how much Auth_Enterprise should do versus the
application. You could very easily implement that at the application
level. If you notice, right now I don't even have different
registration methods because I think I'd like to see a good discussion
by us all on whether or not we should add this. I think the answer is
yes we should include this stuff but if we do so it will make the
administration and support more complicated for end users. For now all
I did was implement the createAccount() method and figured we'd wrap all
the bells and whistles in after we make some final decisions.
> Anyway, hope the like the changes I made. The rest of A&A looks
> pretty good, if a bit of overkill for most people running Geeklog. :)
Just keep in mind that Geeklog 2, from my view point, is less to do with
the hobbyists and more to do with the attractiveness for businesses and
organizations. Granted, our current user base is important to us and I
can't highlight that enough but the days of my writing software with no
sort of compensation is coming to an end. Obviously this is only my
personal take and it may come off a bit selfish but GL2 will basically
end up deciding how involved I stay.
Bottom line is when installing Geeklog 2, Auth_Enterprise should install
itself seamlessly and with little to no hassle so from that view,
nothing should change. My plans to support his is we will include the
Auth_Enterprise table structures into the Geeklog2 database and default
it to the AEPearDBProvider for all account management. Those who want
LDAP or some other configuration will simply have more work (albeit
fairly trivial work).
> I think it'd be cool if we implemented single sign on. I wasn't sure
> if you had any ideas how to implement that, again I'd be happy to chat
> (IRC or voice) with you about it sometime.
Implementing SSO is actually pretty easy. All you would have to do is
add some session tables to the database and, using PHP sessions, we
would serialize the AEServiceUser object there. Using SSO would require
a single login page for all applications so that an SSO token can be
added to the cookies and then a few new methods to the API for verifying
SSO tokens. I think for what we are doing, this would be more of a
version 2 release of Auth_Enterprise.
I'm open to suggestions.
More information about the geeklog-devel