Re^2: HTTPD-Password Self-Management and Recovery

The thing is, I had in the past done a roll-your-own authentication with a form and session-information in the URL as part of the existing application. The application needs some serious refactoring as it's become pretty huge and is no longer maintainable.

I've selected a bunch of modules already, that will replace much of the stuff I had home-grown, but what's missing so far is the authentication part. I would love to do that with SSL client certs, but there's only about two out of a total of around 100 users, that I will be able to motivate to get themselves a cert from a CA I can trust. And one out of the two is me. And I'm not about to set up my own CA with all the trimmings to dish out certs to the rest of my users.

Therefore I've started the new test site dual-login with a choice of client cert or BasicAuth. I could add form-based login and sessions on a parallel virtual host and have the application check, which host it's being accessed through, but I'd probably rather not reinvent the wheel, like I did ten years ago. :-)

If you want to call that being confused, so be it. I was just thinking I might be able to let the webserver handle the authentication, so the main application only needs to worry about the authorization/roles. Add to that a user self-service password-management site on the side. If that's not to be had though, I might just stick with administrating the static .htpasswd by hand, even if I don't look forward to that prospect.

I have taken a look at CGI::Application::Plugin::Authentication in the mean time and while it would be the right module to replace my previous authentication and session handling, it looks as if it is engineered only for checking the credentials, not updating them. Read-only means it's still a lot of coding to get to the management functionality I'm after.

Comment on Re^2: HTTPD-Password Self-Management and Recovery

Replies are listed 'Best First'.
Re^3: HTTPD-Password Self-Management and Recovery by CountZero (Bishop) on Dec 04, 2011 at 11:51 UTC
I have taken a look at CGI::Application::Plugin::Authentication in the mean time and while it would be the right module to replace my previous authentication and session handling, it looks as if it is engineered only for checking the credentials, not updating them. Read-only means it's still a lot of coding to get to the management functionality I'm after. I think that is "as expected". The .htaccess file is a static file in your webserver which must be at all times available and readable by the web-server to administer the authentication process. Many (sub-)processes/threads/workers can read the same file without any problem. But once you will write to that file, perhaps even by different (sub-)processes/threads/workers at more or less the same time, you open yourself to ugly race-conditions or unavailability of the server during the write-process. If you are thinking of changing your set-up anyhow, why not explore a database-centered user administration? Update: That being said, there is Apache::Htpasswd which provides write access to the .htaccess file. I have no idea how secure or safe it is and whether it implements any protection against race conditions. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]
Re^4: HTTPD-Password Self-Management and Recovery by Anonymous Monk on Dec 04, 2011 at 11:56 UTC
Race condition is avoided by using the atomic rename operation Copy original-file to new-file, edit new-file, rename new-file to old-file, rename new-file .htaccess	[reply]
Re^5: HTTPD-Password Self-Management and Recovery by CountZero (Bishop) on Dec 04, 2011 at 12:25 UTC
That will not work. Consider the following: Process A wants to change the pasword file: it copies the password file to newfile-A. Process A does its edits on newfile-A Process B wants to change the pasword file: it copies the password file to newfile-B. Process A renames newfile-A to password file. Process B does its edits on newfile-B Process B renames newfile-B to password file. Now process A's edits are wiped out. Next to the atomic rename opeation, you will need file-locking too: but that means only one writer is allowed at the same time, hence unavailability of the server for all those waiting for the lock to be released. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]
Re^6: HTTPD-Password Self-Management and Recovery by mhi (Friar) on Dec 04, 2011 at 19:01 UTC
Re^7: HTTPD-Password Self-Management and Recovery by CountZero (Bishop) on Dec 04, 2011 at 20:54 UTC


Think about Loose Coupling
	PerlMonks