To address Mikey's question - I am not looking for a way to uniquely identify users. For one, it's just not possible. On top of that, the vast majority of members with to stay anonymous for reasons that I am not even going to begin to state on this list, because we all know where that will end up.
I think you have misunderstood me - I mean't uniquely identifying *clients* - browsers.
I am trying to ensure that one login and one password are specific to one client. Several methods of this include making sure that not more than two IPs use a specific login/password throughout a pre-set threshold, and on top of this, the automatic blocking of IPs that attempt brute-force style attacks. These two items alone would be an invaluable tool in the assurance that logins and passwords are not abused.
As I say, have a look at phpsec.org - the article on sessions is what you want, and it will explain why doing something like that will not work as expected. Some proxies assign new IPs for every request from a single client (AOL in particular). Do you really want to exclude a large proportion of the internet population?
HTH,
Mikey
Mikey -
I'm pretty aware of how it all works. However, the problem lies in the fact that because most of the pre-installed billing software relies solely on .htaccess/.htpasswd-based authentication, it's not possible to just change the whole login system. For the most part, they're still using privative means of authentication which are broken to begin with.
The difficulty is trying to find a solution that would limit access and do all the fancy stuff that we had discussed, without interfering with the pre-existing authentication system. Many of the solutions that I've seen so far include some mod-rewrite hackery that a PHP script or "Gateway" modifies to allow/disallow access based on a given set of criteria.
It's unfortunate that most of the billing systems operate this way. They're not going to change - and I know this because I had worked with the biggest. It would benefit them greatly to investigate other means of authentication, perhaps with a SQL back end and such - but that is a subject I'd not want to bring up here because I know it's been discussed many a time on this list, and I'd hate to start another flame war.
Although it would benefit them greatly, most of their customers expect stuff in a simplistic and uniform manner. Changing the whole login/authentication system would wreak havoc among these clients who are not technically inclined, and is just not possible at this time.
Friends and I have given serious thought to actually starting our own processing solution, but it is not possible at this time due to the large amount of liability that we would inherit. Perhaps though, with time, this will be possible. When that time comes, we plan on having an "open" solution that would try to set some sort of robust and highly configurable standard for this specific application.
Thanks again for taking the time to respond. -dant
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
