Assuming (from the URL you provided) that you're using the CGI module, CGI::Application::Plugin::Authentication is probably as close as you'll get. It has a driver module for .htpasswd authentication, and the default login form provides for a "forgot password" link.

But over there, everything is more or less roll-your-own.

I hate to be the one to disappoint you, but it's pretty much roll-your-own over here, too.

What code have you written, and how does it fail to work as you expected?

I do have a fairly good library and set of pages I wrote for doing web form authentication in PHP, and a hack from a long time ago in Perl, but sadly nothing in Perl to the level you're probably looking for. You're going to have to expect to do some surface work regardless of what module you go with.

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.

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

@planetscape:

When you say here, are you talking about the Monestary's own setup?

I haven't written any code for the password management part yet. I've been relying on the .htpasswd/BasicAuth information for authentication and my application does some additional authorization based on .htgroups. My .htpasswd is currently entirely static and that's not a good idea in the long run.

The password management does not have to be integrated with the application and I was hoping there would be something I could use that more or less just needs configuring and not writing from scratch. I'd like to use what little time I have for further development of the application, not this (nonetheless necessary) sideline.

@keszler:

Thanks, I will take a look at that module.

I simply meant that, in general, you will get more and better responses if you do not appear to be asking others to do your work for you. Monks usually prefer that you show some effort.

In other words, don't just present us with a spec, as neat and complete as it appears to be; demonstrate you've done some brain/legwork.

HTH,

planetscape

The OP asked if there were module(s) to accomplish the task. That's not the same as asking others to do your work for you. Trying to not reinvent the wheel and all that.