BeerOclock Posted April 25, 2009 Share Posted April 25, 2009 Hi guys, love the forum, I think I will be here to stay. I have sort of a high-level question about how to make PHP work for my coding style. First of all, Ive decided to write my own custom sessions because that is what I am used to doing in other languages and it just feels cleaner. Everything related to the user's session is stored in the mySQL database, and the only thing needed to retrieve it is the sessionID. My question is about how to keep my PHP files relatively short and sweet, and how to navigate from page to page. Heres an example of where I am stuck: I have login.HTML which has username and password input box, and a submit button. the form gets submitted to login.PHP. In login.PHP, what I want to do is simple: test the username and password against the database to see if the user is valid, and if so, create a session. If the user is an administrator, redirect them to admin.PHP, and if they are a regular user, redirect them to main.PHP, and if their password was wrong, redirect them back to login.HTML. Thats it. I'm finding this simple task to be impossible with PHP. I dont want the sessionID to be passed around visibly on the URL, I want it to be a hidden form variable on each page. But apparently PHP cant pass FORM data unless you are actually submitting a FORM. In other words when you redirect in PHP, you HAVE to put your data in the url as GET data. Thats no good. So where does that leave me? As far as I know, the next best solution would be to use include(). In my login.PHP, instead of redirecting to main.PHP, admin.PHP, etc, I just include() those files in the appropriate places. But this goes against most of what Ive learned as a programmer. Instead of having a bunch of small modularized PHP files, its more like I'm going to have one giant wholeDamnSite.PHP file. To me, main.PHP and admin.PHP are 2 very separate things, and they should stay that way. They shouldnt be included into the same PHP file on opposite ends of an if statement. I hope people understand what I've said! I hope someone has some high level advice on how to organize all these files, and minimize coupling. Thanks! Quote Link to comment Share on other sites More sharing options...
Daniel0 Posted April 25, 2009 Share Posted April 25, 2009 You could store the SID in a cookie, or you could just use PHP's built-in support for sessions, which you can easily modify to use a database. There is really no reason not to use PHP's built-in features. Quote Link to comment Share on other sites More sharing options...
corbin Posted April 25, 2009 Share Posted April 25, 2009 Also: "But apparently PHP cant pass FORM data unless you are actually submitting a FORM." "FORM" data can be GET or POST. You most likely mean POST in that context though, and that's not a flaw of PHP. Quote Link to comment Share on other sites More sharing options...
BeerOclock Posted April 25, 2009 Author Share Posted April 25, 2009 You could store the SID in a cookie, or you could just use PHP's built-in support for sessions, which you can easily modify to use a database. There is really no reason not to use PHP's built-in features. Thanks for the reply. Even if I used PHP's built-in session support, I would still have the problem of how best to pass around the sessionID. If I'm not mistaken, I would still have to either put the sessionID on the URL or store it in a cookie. So really, the fact that Im writing my own session code is irrelevant. In fact, lets say that I will switch over and use PHP's session code. What are my options for passing around the sessionID from page to page? I really dont want it on the URL. I'm not sure if its bad practice to have it on the URL, but regardless I dont want it there if I can help it. Whats the only other alterntive? Cookies? Im really not a fan of cookies either First of all what if the user doesnt have them enabled... Is there a third alternative? Thanks for your patience, I'm sure this type of thing has been asked before... Quote Link to comment Share on other sites More sharing options...
Daniel0 Posted April 25, 2009 Share Posted April 25, 2009 It has to get to the user somehow, and then the user has to give it back again. HTTP is a stateless protocol. Each request is completely separate from any antecedent requests as far as the webserver is concerned. For those reasons cookies were invented so you had some way of keeping track of people. Quote Link to comment Share on other sites More sharing options...
DarkWater Posted April 26, 2009 Share Posted April 26, 2009 Put your sessionID in a cookie? Or use PHP's built in session handler. It's pretty simple to get working. Quote Link to comment Share on other sites More sharing options...
BeerOclock Posted April 26, 2009 Author Share Posted April 26, 2009 Put your sessionID in a cookie? Or use PHP's built in session handler. It's pretty simple to get working. I'm pretty sure those two things are one in the same... Therefore you have confused me. I'm reading up on all this crap, to make sure I use the best method. Quote Link to comment Share on other sites More sharing options...
coalgames Posted April 26, 2009 Share Posted April 26, 2009 Put a sessionID in a cookie on the client. Put an ipagent hash on the server database. Ex: md5( $_SERVER['REMOTE_ADDR'] . $_SERVER['http_user_agent'] ); On each page, check if the user has a cookie that is valid (32 chars with a-z and 0-9). Then if it is valid, check against the database. If there is a match, then the person can log in. If there is no match, then the person is not logged in. This requires the use of cookies though. Good luck. Quote Link to comment Share on other sites More sharing options...
Daniel0 Posted April 26, 2009 Share Posted April 26, 2009 I really must say that I still do not see the incentive for not using the built-in session functionality that works quite fine already. Quote Link to comment Share on other sites More sharing options...
coalgames Posted April 26, 2009 Share Posted April 26, 2009 I feel that the built in one is not portable enough to distribute a script. Some PHP configurations have disabled the session_set_save_handler() function. Most popular and professional PHP scripts such as Wordpress and Phpbb dont use the built in sessions. Although the built in php sessions functions work fine, it would not be good on massively distributed scripts. Quote Link to comment Share on other sites More sharing options...
DarkWater Posted April 27, 2009 Share Posted April 27, 2009 Put your sessionID in a cookie? Or use PHP's built in session handler. It's pretty simple to get working. I'm pretty sure those two things are one in the same... Therefore you have confused me. I'm reading up on all this crap, to make sure I use the best method. I meant if you planned to circumvent the built-in handlers, you would need to store your own session ID in a cookie without using the session_* functions. And that session_set_save_handler being disabled non-sense is very paranoid. Also, Wordpress and phpBB do use the standard PHP sessions. They may have some wrapper functions, but on the lowest level, it's what they're using. Quote Link to comment Share on other sites More sharing options...
Potatis Posted April 28, 2009 Share Posted April 28, 2009 I dont want the sessionID to be passed around visibly on the URL, I want it to be a hidden form variable on each page. But apparently PHP cant pass FORM data unless you are actually submitting a FORM. In other words when you redirect in PHP, you HAVE to put your data in the url as GET data. Thats no good. Hmm, the login script I use is a form, but it doesn't put anything in the URL area of the browser, and the username is stored in the session variable: $_SESSION['username'] = $post['username']; From there, all the pages they visit are logged as well as the time they viewed the page and even their IP. Is that what you were looking for? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.