Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I have an HTML login form which is checked by login.cgi. If they're clear, it redirects to www.page.com/username/ otherwise it fails like a good little login script. *pets script on head*

Each folder will have a script which reads in and displays particular files found in their specific folder.

The problem/question is from this..

The admin sets up all the login data for all users in his own admin panel. He includes some text which must be included for each individual user (each user has their own welcoming message or account details displayed on screen).

So each user will essentially have their own script to read directory files and post a custom message to them. Unless you can think of a way to have ONE centralized script which I can get for all accounts, I have no idea how to get this to work.

When the admin creates the account then, the script would need to move the index.cgi to the new folder they created. But on top of this, the script would also need to automatically edit the source code for the file for that particular user.

So essentially it would be a CGI configuring another CGI after creating it in a directory.

I have zero idea if anyone is understanding any of this, I am just confused as to what to do and how to do it. I would like ONE script for everyone but they are redirected to their own folders.

Any ideas or comments are welcome.

  • Comment on Ideas on how to redirect users to a specific index

Replies are listed 'Best First'.
Re: Ideas on how to redirect users to a specific index
by castaway (Parson) on Oct 13, 2004 at 05:22 UTC
    You problem seems to be, how to write a single cgi script, that can be used to show directories, files, individual info, for lots of different users ? This is a Perl script, I'm assuming since you're asking here.

    My answer to that would be, use a database, use CGI params, use rewrite as eric suggested. It just needs to LOOK like they're in their own folders, right? Or is there some physical need to actually be there? One centralized script can read the individual settings/messages from a database, according to the logged in user, and output the appropriate HTML. (Thats how PerlMonks works, essentially). Heck, I have a script that pretends its an entire web server, every single request for any page at all just goes through one script.

    You may want to symlink the script into each of the user directories, if thats easier than rewriting URLs.. (No idea, not much of a cgi buff myself.)

    C.

[reply]
      Actually I had the idea of using url_params already. The admin already uses this ability to go between functions but I like to keep these clean. Clean as in, no more than one step deep. ie www.page.com/cgi-bin/script.pl?function=add or www.page.com/cgi-bin/script.pl?function=edit. I don't like going deeper into things like www.page.com/cgi-bin/script.pl?function=add&user=bob&page=7 .

      I could write it to do that, but it gets difficult writing to screen just information needed when using so many params at one time and keeping them organized.

[reply]
Re: Ideas on how to redirect users to a specific index
by tachyon (Chancellor) on Oct 13, 2004 at 06:31 UTC

    *Boggle*

    First things first. You have a login script that redirects to http://domain.com/username/. So why would I ever login? I would just bookmark that dir. I would probably also have a guess to see what other directories there might be. Using your current logic you may as well not have a login.

    Having N copies of a script to deal with N users is stupid. Besides the fact that you don't have any form of secure login this is a maintenance nighmare. If you did have a decent login you could quite happily use a central script as this script would check login status/identify the user, and then let them do stuff to their own stuff and only their own stuff.

    You seem to be under the impression that redirecting users to 'their own folders' makes any useful difference to anything. It is also apparent that you plan to allow execution of CGI scripts in any directory. If users can create files, upload, rename files then they can probably create their own CGIs. If they can create their own CGIs you might as well give them your Administrator password now.

    I sincerely recommend you post a new question that states what exactly it is you are trying to achieve and asks for advice about good ways to achieve that. Without being unduly rude your current plan seems very sub optimal.

    cheers

    tachyon

[reply]
      Well no, you cannot bookmark any folder because there will be a blank index along with an index.cgi which checks cookies to see if they logged in. Simply book marking the folder won't do anyone any bit of good, even if they logged in an hour ago because you can't see the files in the folder.
[reply]

        OK so you are setting a login cookie. So what is stopping you mapping that to the username? Having done that any cgi on your site can determine the user based on the (usually sessionID) cookie. There is no need for one copy per user, nor is it a good idea. You will find bugs. When you do it is easier to fix one script than 100s or 1000s of near identical ones.

        cheers

        tachyon

[reply]
        I would have to agree with tachyon, this might not be the best way of doing things... If you are going to the trouble of using cookies why not use multiple params in the URL? Are you using any kind of database?

        Ideally, I would think you would want to set something up like this:
        1. User tries to log in
        2. You validate the user (we are going to assume this is a valid user)
        3. You then write a cookie with some MD5 value. You also write this MD5 value along with a userId (this could become a session Id or whatever) to the database (We use MySQL for this)
        4. Now you have a semi-secure way to use 1 script and just get the MD5 string from the cookie and look up the user information that you need.

        *Note you could also change the MD5 string and reset the cookie on every page hit the user does for more security. But you need to be careful if you have pop up's that need to also validate the user and there could be an issue with the user hitting refresh in the middle of a request.

        *Update -- You could also look into CGI::Session

        This is my first time posting on PM, but I have been lurking around ever since a co-worker informed me about the site. Make sure you take the others responses as constructive criticism and not an attack on how you are doing things. One thing I have noticed is that this is a very smart and savvy community and if you can deal with some constructive criticism you will usually end up with the correct way to do things.

        Let me know if any of this does not make sense (again this is my first post), and any of you more experienced guys feel free to rip my suggestion apart :)
        ----------------------------------------
        StrebenMönch (I stole this sig idea, just wanted to see what it looks like)
[reply]
Re: Ideas on how to redirect users to a specific index
by pg (Canon) on Oct 13, 2004 at 05:04 UTC

    It seems to me that, you had the impression that you can only send out physical HTML files.

    Although URL's could be actually mapped to a .html file, and the URL could identify the physical path of the file, that is not a must. The content could be composed on fly and just send out as a stream of octets.

    URL is the identifier of some content rather than a file, although the content could be the content of a file.

[reply]
Re: Ideas on how to redirect users to a specific index
by eric256 (Parson) on Oct 13, 2004 at 05:03 UTC

    One way to do it would be to use apache rewrite rules to change www.page.com/username/ into www.page.com/script.cgi?u=username. Then you have one script that takes care of everything. I'm sure there are otherways but thats the first thing that came to mind when reading your problem.


    ___________
    Eric Hodges
[reply]
      "One way to do it would be to use apache rewrite rules to change www.page.com/username/ into www.page.com/script.cgi?u=username."

      What is the difference? Indeed, they are the same. The information contained in those two URL's are exactly the same, although they visually appear to be different. They both contain the username.

      www.page.com/username/ does not require a seperate physical folder for the username, unless we are saying that URL always matches the path to a file, which is not true. It is all about the logic on the server side, and how it forms content for an URL. There is absolutely no need to map www.page.com/username/ to some file, say index.html, in directory $SERVERHOME/username.

      If he has a piece of logic to deal with www.page.com/script.cgi?u=username, the same logic with very slight modification could be used to deal with www.page.com/username/

[reply]

        I don't understand what you mean. I was saying that when a user types in http://www.page.com/username/ you can make your server act as if they typed http://www.page.com/script.cgi?u=username. Which kind of sounds like what you are saying. The user still sees page.com/username/ and you get one script to do everything in, which sounds like what the op was requesting.


        ___________
        Eric Hodges
[reply]

Back to Seekers of Perl Wisdom