extension Class to Auth

[jsWalter]

I have an extension Class to Auth and I'm looking for some folks to hammer
on it a bit and give feed back.

Class: AuthUser
- add user (well, Auth does that now, so its gone)
- remove user (well, Auth does that now, so its gone)
- change password (well, Auth does that now, so its gone)
- case sensitive ID match - some DBS don't
- limit login attempts (as far as it can go on a browser)
- return to original page after login

next ver will have groups and level handling.

If your interested, please contact me offline.

Thanks

Walter

[Tim Van Wassenhove]

In article <jd*********************@newssvr28.news.prodigy.co m>, jsWalter wrote:

I have an extension Class to Auth and I'm looking for some folks to hammer
on it a bit and give feed back.

Class: AuthUser
- add user (well, Auth does that now, so its gone)
- remove user (well, Auth does that now, so its gone)
- change password (well, Auth does that now, so its gone) - case sensitive ID match - some DBS don't
The place to handle this is in the class that implements Auth and
uses a DB.
- limit login attempts (as far as it can go on a browser)
Perhaps you can log all attempts somewhere, and then count how many
attempts faild. Based on that you can issue a delay...
- return to original page after login

An Authentication class does not need to know about pages. All it
has to do is authenticate users.
--
Tim Van Wassenhove <http://home.mysth.be/~timvw/contact.php>

[jsWalter]

Tim Van Wassenhove" <eu**@pi.be> wrote in message
news:2i************@uni-berlin.de...

In article <jd*********************@newssvr28.news.prodigy.co m>, jsWalter

wrote:

I have an extension Class to Auth and I'm looking for some folks to hammer on it a bit and give feed back.

Class: AuthUser
- add user (well, Auth does that now, so its gone)
- remove user (well, Auth does that now, so its gone)
- change password (well, Auth does that now, so its gone)

- case sensitive ID match - some DBs don't

The place to handle this is in the class that implements Auth and
uses a DB.

Yes, that was where I orginally "fixed" this.

But the maintainers didn't think it was an issue so my "patch" was denied.

So, I added it to my extension.

- limit login attempts (as far as it can go on a browser)

Perhaps you can log all attempts somewhere, and then count how many
attempts faild. Based on that you can issue a delay...

This count is kept in the session. And if you try to log in before the
"timeout" length is done, you get the same message (or jumo to "your"
message page)

Yes, I understand this is not rock solid security. But, it's a start, and
I'm hoping someone can enlighten me on how to tighten this down a bit more.

- return to original page after login

An Authentication class does not need to know about pages. All it
has to do is authenticate users.

Exactly correct, thus this "extension" to the PEAR::Auth Class. This sits on
top of Auth, which handles the authentication process just fine.

This extension handles the other mundane processes needed to create a site
passed on authentication.

This does not replace Auth, it just adds to it.

So I take it for your comments your not interested in looking at this and
giving constructive comments.

Thanks for your thoughts.

Walter

[Tim Van Wassenhove]

In article <bz*****************@newssvr33.news.prodigy.com> , jsWalter wrote:

Tim Van Wassenhove" <eu**@pi.be> wrote in message
news:2i************@uni-berlin.de...

Perhaps you can log all attempts somewhere, and then count how many
attempts faild. Based on that you can issue a delay...

This count is kept in the session. And if you try to log in before the
"timeout" length is done, you get the same message (or jumo to "your"
message page)

I suggested to do the counting per account and global on the
server-side. Because, i don't think a hacker will be nice enough to
store your cookie :o)

An Authentication class does not need to know about pages. All it
has to do is authenticate users.

Exactly correct, thus this "extension" to the PEAR::Auth Class. This sits on
top of Auth, which handles the authentication process just fine.

This extension handles the other mundane processes needed to create a site
passed on authentication.

This does not replace Auth, it just adds to it.

Imho, i think you are mistaken here. If you are building a class(1) that
also can redirect etc, you have a has-a relationship with auth.

In the case where you implement the functions of auth, fe using a
database your class(2) has a is-a relationship with auth.

Giving a class(1) with an has-a relationship to class(2). And
your class(2) has an is-a relationship with pear::auth.

--
Tim Van Wassenhove <http://home.mysth.be/~timvw/contact.php>

[jsWalter]

>Tim Van Wassenhove" <eu**@pi.be> wrote in message
news:2i************@uni-berlin.de...

In article <bz*****************@newssvr33.news.prodigy.com> , jsWalter wrote:

Tim Van Wassenhove" <eu**@pi.be> wrote in message
news:2i************@uni-berlin.de...

Perhaps you can log all attempts somewhere, and then count how many
attempts faild. Based on that you can issue a delay...

This count is kept in the session. And if you try to log in before the
"timeout" length is done, you get the same message (or jumo to "your"
message page)

I suggested to do the counting per account and global on the
server-side. Because, i don't think a hacker will be nice enough to
store your cookie :o)

mm, yes. Another example of my limited knowledge of sessions.

I tried the "standard" Auth example page (I made) with cookies off.

It never got off the login page. I tried hitting a secondary page, it jumped
to login page, and never left it.

I tried the same process with my Auth extension. Same result.

The login limit was never triggered. So, I need to "add" a server side
tracker as well.

thanks for the idea.

An Authentication class does not need to know about pages. All it
has to do is authenticate users.

Exactly correct, thus this "extension" to the PEAR::Auth Class. This sits on top of Auth, which handles the authentication process just fine.

This extension handles the other mundane processes needed to create a site passed on authentication.

This does not replace Auth, it just adds to it.

Imho, i think you are mistaken here. If you are building a class(1) that
also can redirect etc, you have a has-a relationship with auth.

Sorry, you lost me here.

"you have a has-a relationship"

Sorry, I can't grok what this means.

I am building a class that can redirect, check login count (once I fix it),
and will have user access privilege features (soon).

In the case where you implement the functions of auth, fe using a
database your class(2) has a is-a relationship with auth.
My class is built on top of Auth, so Auth can take care of all the
authentication issues and I can focus on the other things.

My current examples use a DB, but, by using Auth, it can handle other
"containers" as well.

Giving a class(1) with an has-a relationship to class(2). And
your class(2) has an is-a relationship with pear::auth.

Ok, I really don't follow this. Sorry.

Thanks for your ideas.

Walter