Session / User Management

[tanger]

Hello,

before I heard of CGI::Session, I had my own little sub routines that would authorize,verify, expire, and logout.

I have a web site that has Certain sections that require the user to be logged in as a member. There are also certain sections of the website that are just regular .html pages and free to public/members.

When I first started to build this site about 2 and a half months ago, I did not intend for certain sections to require users to be logged in. (I only intended there to be a members only section that had certain areas for members).

SO now I have my site with some pages that are Perl files and some pages that are just regular HTML. So lets say someone comes to the home page...which is index.html. He logs in, and now hes at index.html again. But then when he goes to another HTML page this will then cause a breakage in the user/session tokens when being passed through. This will also happen vice versa, when the user goes to a members area page, then goes back to a html page...a breakage will happen again.

Does anyone know a better way for me to manage my tokens, WITHOUT re-writing all the html files into .pl files to pass the session tokens? I was thinking of one main script that checks/verifies the session token and then uses a HTML Template module to read the html files and print them out? Then have some sort of regex to append all session tokens to the end of urls in the html files.

The way I was originally planning to do this was to re-write all 12-13 html files and convert them to PERL where it can do the session token management routines. But this will cause 12-13 html files and 12-13 .pl files.

Thank you! tanger

[TedPride]

Instead of passing session tokens via URLs, use cookies. Cookies will persist during the periods your users are looking at .html pages.

[rjsaulakh]

you can have a look at following modules CGI::Session, CGI::Application and CGI.pm, CGI::Cookie
use cookies to send session id to the user and then fetch those cookies for every page visited by the user
you can also use hidden fields but cookies will be fine
let me know if i can help you better

[johnnywang]

In general, I'm of the opinion that authentication and authorization should not be part of the application, instead it should be an add-on. That is, in principle, one shouldn't need to change application code to add authentication. The simplest way, in Apache with Basic authentication, is to put (alias, mod_rewrite) the member-only apps in a directory, and protect it with, say, Apache::AuthDBI.

[tanger]

Hey,

Thanks for the replies everyone.

I'm on a windows and running IIS-- :(

The thing with cookies is that how will it know to update / expire if the member only browses through html files? I would need some sort of coding to constantly update, which is why I was thinking about converting the .HTML files to a PERL file.

Thank you, tanger

[Joost]

The whole point of using sessions is that you DONT need to update anything on the client side (apart from setting up the initial cookie to store the session id). That means your sessions will keep working as long as the cookie & session is still valid. I might be misinterpreting you, though, because I am not sure what you would want to "constantly update" anyway.

[Anonymous Monk]

If you must store your session in the URL do it as $QUERY_PATH, that means use a .pl directory. If you are on a .html file, configure your server to ignore this part of the URL and use relative links. Example: http://server/s4563453/index.html should serve /index.html , from there <a href=new.pl > would try to get http://server/s4563453/new.pl which should redirect to http://server/new.pl/s4563453 (in apache there is mod_rewrite for this, don't know about IIS).