Jump to content

foxy

New Members
  • Posts

    4
  • Joined

  • Last visited

    Never

Profile Information

  • Gender
    Not Telling

foxy's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. Re being a smartass, I was referring to this process of writing session handling functions and inserting them behind the exisiting PHP ones. Why go to all that trouble to roll-your-own MySQL based solution only to hide it behind the PHP functions? That's just more hidden layers of depth. If I came along that code and wondered why sessions were encountering problems, it'd take me longer to figure out why because it would look as if the standard PHP sessions were doing it, not custom code. I wanted a MySQL based solution for a reason, so please don't compare apples (file-based) and oranges (MySQL based). Is anyone actually going to answer the very simple question I asked?
  2. [!--quoteo--][div class=\'quotetop\']QUOTE[/div][div class=\'quotemain\'][!--quotec--]Session sets a cookie, which only stores the session id[/quote] Which is exactly what I do with my custom method. So what is the advantage of using PHP sessions over my method? Also, I question why you have just told me at length about the issue of an attacker getting the cookie off the same computer, [b]since I made clear in my post that I was 100% aware of this.[/b] So, can I get an actual answer to the above question? I just want to make sure that there is no security or implementation issue here that I have missed, I am not looking for basic info about sessions. As far as I can see, my method is just as secure as PHP sessions. Is this correct or not? If not, why not?
  3. Erm, PHP session handler has to store something on the client too, otherwise there is no state... if it doesn't put that in a cookie, where does it put it? How is that more secure than dumping a generic 'ID' in a cookie? It's still theoretically possible to transplant it.
  4. Hey, I'm currently reading around the topic of sessions, and I've come to the conclusion that the PHP sessions handling is too complex for what I need. I don't need to store session variables because my databases already handle all of that. I just need a session check that spits out a UserID so that I know who is logged on, the rest is accounted for. I'd thought of doing this with a MySQL table of SessionID|UserID and storing the SessionID in a cookie on logon and checking that cookie in later scripts. The book I'm reading has an example of a MySQL-based solution that does something weird involving writing custom session functions and inserting them behind the standard PHP session handling functions. Thing is that this seems overcomplicated. I don't need anything except a UserID, and to be honest I'd rather avoid stuff like this, as it seems to make something very simple in concept into something arcane and hard to figure out. I'm not a big fan of overcomplicating something for the sake of being a smartass. So, is my custom method OK do you think? I would be just shoving a SessionID into a cookie, and later retrieving it from $_COOKIE and comparing it to the SessionID|UserID to check for a login. Would there be any security risks arising from it? (I presume that transplanting cookies is a risk with PHP sessions anyway?) Is there a 'good practice' reason why I shouldn't do this? Thanks.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.