Crossposted at StackOverflow. It's considered polite to inform about crossposting, so that people not attending both sites don't waste their time hacking a problem already solved at the other end of the internet.
| [reply] |
Check the Dancer2::Plugin::Auth:: series of modules if you want to do authentication in the Dancer2 framework.
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 My blog: Imperial Deltronics
| [reply] |
There are plenty for vanilla CGI. If you are using some other framework (Catalyst/Mojo/Dancer2) that will likely have its own built-in widgets.
| [reply] |
| [reply] |
This module covers authentication, authorization and other user management:
https://metacpan.org/pod/Web::Authenticate
It does not include password recovery, but it could be easily implemented with this module.
| [reply] |
| [reply] |
The "uninitiated" might also call a proper temporary one-time access token which enables you to change your password, "password recovery".
| [reply] |
As you may have guessed, or found by searching http://search.cpan.org, there’s a never-ending supply of modules to help you handle these chores. You should first give very careful consideration to exactly how you need to handle these tasks in your web-application, then look for Perl modules to help you do it. Nearly all of the work should already have been done for you, so the question is not “how to do it,” but “what to do.” (Whew!)
In a corporate setting, you probably will find that LDAP (nee Microsoft OpenDirectory™) is probably already in use. Therefore, you probably should use that for both authentication and authorization, working with the company’s security department to set-up the details. (Another technology that you might see is Kerberos.)
For instance, you might be able to use Apache (or nginix, or IIS) directives, at the <VirtualHost> level, to restrict access to the entire site, based on LDAP-determined characteristics of the particular corporate logged-on user ... and to prohibit access by the general public. This enables you the security department to centrally limit the site only to authorized users. This also enables your software to query to determine who the user is, and what the security department has designated that he is to be allowed to do. Once again, CPAN packages have done all the dirty-work for you.
I myself made the embarrassing mistake of creating a home-made, “open web user” authentication system for a company web site ... before being politely and graciously told that, in the (one and only) internal context where the site would be deployed, my efforts were unnecessary. Apache would use LDAP to protect the site-at-large, and simple LDAP queries (made by Perl modules ...) would thence handle authorization. (“Oh ...”) :*{
| [reply] |
| [reply] |
