in reply to Ideas on how to redirect users to a specific index

*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

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

Replies are listed 'Best First'.
Re^2: Ideas on how to redirect users to a specific index
by Anonymous Monk on Oct 13, 2004 at 06:51 UTC
    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.

      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

      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)