Re: Status & CVS & objects

[Aaron Turner <aturner@linuxkb.org>]

The only good cookie is one soaking in cold milk.  Yum.

On Thu, 4 Nov 1999, Jason Pincin wrote:

> Your point?  They are cool - I like them, but you have bunches of peeople
> out there that feel accepting a cookie is the equivilent of selling
> they're soul.  :)  They're prolly all BSD lovers.
> 
> /me dodges the blow from spencer.
> 
> Just kiddin.
> 
> On Thu, Nov 04, 1999 at 09:19:58AM -0500, Spencer Portee wrote:
> > cookies are cool though
> > 
> > On Thu, 4 Nov 1999, Jason Pincin wrote:
> > 
> > moo> Yeh - we can't require cookies.  crypt is cool - I assume your going to be
> > moo> storing passwords via php's crypt() function then?  Cool.
> > moo> 
> > moo> As far as authentication... cookies are optional.  But we are using httpauth in
> > moo> order to have session level authentication.  I want someone to come up with a
> > moo> way to do this in php so an auth doesn't take TWO connections to the DB, as now
> > moo> it requires one php and one mod_perl. 
> > moo> 
> > moo> If someone doesn't give it a look soon, maybe I'll give it a gander when I
> > moo> impliment the object security which was #2 or 3 on my list...
> > moo> 
> > moo> What we are making optional with cookies (and thus you should account for on
> > moo> signup) is:  if the user chooses to accept an account cookie - they won't have
> > moo> to login every time they return to the site to restore there preferences.  
> > moo> 
> > moo> While I'm thinking of it - I think we should make this option only valid for
> > moo> standard-security users.  Run of the mill who just want to customize the things
> > moo> available to them, but don't want a login prompt with every visit.  Then, we can
> > moo> either store there site passwd as a cookie, or some kinda checksum or sumthin,
> > moo> and have them auto-auth when they visit - or sore they're site preferences as
> > moo> cookies... nah... the checksum or sumthin would werk better.
> > moo> 
> > moo> At any rate - my point is - this should be disabled for users with advanced
> > moo> privleges.  People with admin access to branches of the tree should not be
> > moo> allowed to store auth cookies methinks.  Someone finds out, walks up to there
> > moo> browser, and voila - hoses our tree.
> > moo> 
> > moo> Thoughts?
> > moo> 
> > moo> Jason
> > moo> 
> > moo> 
> > moo> On Thu, Nov 04, 1999 at 12:09:41AM -0800, Micah K Yoder wrote:
> > moo> > ok..........
> > moo> > 
> > moo> > am ready to test my attempt at getting signup.php3 working with the
> > moo> > object system, but....
> > moo> > 
> > moo> > the CVS permissions really do need to be fixed.  CVS aborts before it
> > moo> > gets to users.  when I checkout, I can do cvs co main/users but
> > moo> > webupdate main doesn't allow that.
> > moo> > 
> > moo> > when I hit http://dev.linuxkb.org:81/users/tools/signup.php3 I get a 404
> > moo> > Not Found.  Why am I not even getting the *old* signup.php3?  It used to
> > moo> > be there...
> > moo> > 
> > moo> > Passwords... Aaron, you might want to do what you need to do to switch
> > moo> > over to crypt() for authentication, cause that's how it's gonna work! 
> > moo> > :-)
> > moo> > 
> > moo> > Speaking of authentication, there's another way that we use at work, but
> > moo> > it REQUIRES cookies (at least temporary ones).  It's somewhat slick, but
> > moo> > I guess the required cookies make it out of the question...???  It
> > moo> > involves getting an md5() hash of the username, time logged in, and
> > moo> > maybe something else... I'd have to check...  and storing it in a
> > moo> > database table.
> > moo> 
> > moo> -- 
> > moo> Jason
> > moo> http://vodka.linuxkb.org/~chardros
> > moo> 
> 
> -- 
> Jason
> http://vodka.linuxkb.org/~chardros
> 

--
Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization  http://linuxkb.org/
Because world domination requires quality open documentation.