Ajax and sessions #2

[tomfmason]

[list]ok I am working on an ajax chat script.
[hr]
@ober

You told me to move on to something more complicated..lol
[hr]
Anyways, back to the question.

I know, from reading the other post, that there are some issues with sessions and ajax. So my question is what would be the best way to store session data.

What I am attempting to do is create a support chat script. The part that is causeing the issue is when a new chat is started I want to store certain information in sessions, like, for instance, nickname and maybe ip address.

I am wondering if I should do this in by backend processing file or ? Should I maybe set a cookie with the information in it.

The main reason that I am thinking that I will need sessions is that I am unsure how I will tell the chat requests apart.

So say I have user1, user2 and user3 waiting to chat. How can I distinguish between the three.

The way that I my chat db set up is:

chat_users
[list][*]chat_id
[*]name
[*]email
[*]department
[*]status[/list]

chat text:
[list][*]text_id
[*]chat_id
[*]text
[*]status_update[/list]

So I guess my questions is how can I store ether the chat_id or the chat name in a session variable.

Can the backend processing file store session information or ??

Did I explain my question adiquitly?

Any suggestions would be great.

Thanks,
Tom[/list]

[tomfmason]

I was thinking (dangerous I know)..

Maybe what I should do is obtain the users ip and then store that that in the db. Then I could use an onload call to a function that would check to see if the status is ether waiting or chatting. If it is not then I could have the user loggin to the chat session.

I think that I will try this.

Any suggestions on a better way would be great.

Thanks,
Tom

[448191]

[quote author=tomfmason link=topic=108729.msg437699#msg437699 date=1158726705]
I was thinking (dangerous I know)..

Maybe what I should do is obtain the users ip and then store that that in the db. Then I could use an onload call to a function that would check to see if the status is ether waiting or chatting. If it is not then I could have the user loggin to the chat session.

I think that I will try this.

Any suggestions on a better way would be great.

Thanks,
Tom
[/quote]

You're forgetting an ip is not nessecarily a unique 'characteristique'. You could be dealing with users on a network that shares an ip, and users that no longer have the same ip, because their ISP assigned them a new one. You're better off using sessions. Using session_write_close() you should be fine, as long as you don't do multiple (in rapid succession) asynchronous ajax requests. Only then will you be dealing with the issue of 'race conditions'.

[ober]

Keep in mind that AJAX is not a cure-all solution.  I personally would never use SESSIONS in conjunction with AJAX.  The whole point of using AJAX is to be able to talk to objects on the server like XML files, databases, and text files.  And I'm sure someone is going to pipe up and say "but a session is an object!"... DUH.

The whole point of sessions is to have data persist from page to page.  You're working on one page with AJAX, so you use other things that work with that medium.

Get my point?

[448191]

[quote author=ober link=topic=108729.msg437878#msg437878 date=1158756332]
The whole point of using AJAX is to be able to talk to objects on the server like XML files, databases, and text files.  And I'm sure someone is going to pipe up and say "but a session is an object!"... DUH.

The whole point of sessions is to have data persist from page to page.  You're working on one page with AJAX, so you use other things that work with that medium.

Get my point?
[/quote]

Not really... ???

No offence, but I honestly see absolutely no reason why you shouldn't use the session_* in conjunction with Ajax.

Sessions in general (wether using session_* or not), traditionally where about having data persist from page to page, but with the goal of maintaining state in mind. That hasn't changed, wether the browser wants a whole page or some updates. Maintaining state on the client doesn't sound very secure to me, especially when used to autenticate. Also, like in the original 'Ajax and Sessions' thread, state will be lost upon page refresh if not maintained on the server.

It doesn't matter if the server serves a whole page or portions of it, it needs to know 'who' it is dealing with.

[ober]

And you can do all of that with a database or a flat file.  Sessions have their vulerabilities and you're really stretching the intent of AJAX if you're trying to maintain state through sessions.  Hell, most major applications don't even use sessions to maintain state.  They store the values on the backend and retrieve them as needed.

You're obviously entitled to your opinion, but you're wrong.

[448191]

[quote author=ober link=topic=108729.msg438097#msg438097 date=1158768219]
And you can do all of that with a database or a flat file.  Sessions have their vulerabilities and you're really stretching the intent of AJAX if you're trying to maintain state through sessions.  Hell, most major applications don't even use sessions to maintain state.  They store the values on the backend and retrieve them as needed.

You're obviously entitled to your opinion, but you're wrong.
[/quote]

If there is a better way to maintain state than using sessions (not exclusively session_*, but simply sessions in general), I would like to know about it, so I can implement it.  :)

I would be very satisfied with a resource on the subject.

[ober]

I don't understand the confusion.  A database or a flat file could be used to implement a "state" management system.  I already said that.

[448191]

[quote author=ober link=topic=108729.msg438146#msg438146 date=1158771722]
I don't understand the confusion.  A database or a flat file could be used to implement a "state" management system.  I already said that.
[/quote]

I don't understand how that's different from a session. The "state" management system as you call it, would have to know which state a client is in, thus the client has to be id'd, the server will then know what state goes with what client, effectively making this a session management system. I think.

[ober]

So you're saying you can't ID an individual with a database record or a entry in a flat file?  Wrong again.  The session doesn't know what state the client is in any better than a database or a flat file would.

[448191]

[quote author=ober link=topic=108729.msg438180#msg438180 date=1158773150]
So you're saying you can't ID an individual with a database record or a entry in a flat file?  Wrong again.  The session doesn't know what state the client is in any better than a database or a flat file would.
[/quote]

That's not what I'm saying. Of course you can associate data with a client's id, that is not the point. What you can not do is associate a client to data in the database if you haven't identified the client. That is where the id comes in.

What I'm saying is: If you want to maintain state for clients, the clients have to be assigned an id. Then in the system, wheter you call it a session management system or an "state" management system, [u]the're the same[/u], the client is identified, and the appropiate data becomes available at some level. Even if you could determin a clients identity by some other factor than a tradional session id being passed by a cookie, request variable or hidden form field, it would still be a session.

Sessions in all it's colours and flavors, are the only way to properly maintain state. Even with Ajax applications.

You can use javascript to send a string representation of the state to the server, but doing so with states that are restricted to a spefic user (eg 'restricted area') doesn't seem very safe, as it would require sending a string (on the preceding response) with the previous state to the browser (meaning continuesly passing a string representation of the state from server to client). That information could easily be misused, I think.

I don't particularly 'like' arguing with you, but I don't think I am wrong.

[ober]

No, no, and no.

You can properly identify a client within a database.  You don't have to have people registered in your database to generate a random ID and tie it to a specific person.

[quote]Even if you could determin a clients identity by some other factor than a tradional session id being passed by a cookie, request variable or hidden form field, it would still be a session.[/quote]
That doesn't make any sense. 

[quote]Sessions in all it's colours and flavors, are the only way to properly maintain state. Even with Ajax applications.[/quote]That'd a bold statement, and it's wrong. 

Look, you can think what you want, but there are plenty of ways besides sessions to "maintain state".  Some would argue that sessions aren't even secure, and I would tend to agree with them. 

You need to stop thinking in absolutes and start realizing that there is a variety of ways to attack a problem and some may be better than what you currently use.

[ober]

And one more thing... "sessions in all it's colors and flavors" doesn't make any sense either.  Sessions are sesssions.  It's an object.  How can it have more than one color or flavor?!?!

[448191]

[quote author=ober link=topic=108729.msg438281#msg438281 date=1158782054]
No, no, and no.
[/quote]

Yes, yes and yes.

[quote=me]Sessions in all it's colours and flavors, are the only way to properly maintain state. Even with Ajax applications.[/quote]

Earlier in this thread, I was hoping you would prove me wrong on that. What I think is going on here that you might be fading the line between sessions and php's session management system, those are not the same. Sessions (session layers) are used in many transfer protocols, HTTP not 'really' being one of them (as soon as the status changes to "200 OK" the connection is lost and the session ended). To maintain some sort of state in applications that are dependand of HTTP, session behaviour must be implemented some other way.

While php packs it's own build in session management system, in the form of a couple of session_* functions and a $_SESSION superglobal, this isn't the only way to employ sessions in php.

[u]All one needs is way of identifying the client within a session, a storage method, and code to retrieve and set data using that method, for that perticular client.[/u]

Anything that performs that, is a session management system. I'm thinking up a custom session management system as I'm writing this.

With Ajax applications, one [i]could[/i] maintain state client-side, but that would require the client to tell the server [u]exactly[/u] what it wants, and can therefore never be used in an application that requires authentication. But even then the state would be lost upon page refresh.

Sessions are not objects (unless you use instantiations of a class called 'Session' of course).

[quote author=ober link=topic=108729.msg438281#msg438281 date=1158782054]
You can properly identify a client within a database.  You don't have to have people registered in your database to generate a random ID and tie it to a specific person.
[/quote]

I'm thinking you're not understanding what I am trying to say. I'm NOT saying you can't use a database to store data by client id, I'm NOT saying you need 'people' registered in a database, what I'm saying is you need to indentify the client by some characteristic, typicly string assigned by the server (id), I order to be able to retrieve the data specific for that client within this session.

You can NOT identify a client within a database. Assuming you mean identifiying a client by use of the data in the database, you can not get [u]client specific[/u] data from a database (or a flatfile it doesn't matter in this case), if you do not know what client to fetch for.

E.g. the client has to identify itself first.

[quote author=ober link=topic=108729.msg438281#msg438281 date=1158782054]
That doesn't make any sense. [/quote]

Well, it does. In order to start a session, the client has to have an identity. Currently, the only way that actually works that I know of (for HTTP dependant applications) are passing an id by the above mentioned methods.

[quote author=ober link=topic=108729.msg438281#msg438281 date=1158782054]
Look, you can think what you want, but there are plenty of ways besides sessions to "maintain state".  Some would argue that sessions aren't even secure, and I would tend to agree with them.  [/quote]

There are plenty of ways to employ sessions other than the standard, build-in session management system in php. There aren't any ways to maintain state other than using sessions.

True that session in HTTP dependant applications aren't that secure (you have to watch session hijacking and session fixation), but these are problems with the concept of sessions in the realm of all HTTP dependant solutions, not just php.

[quote author=ober link=topic=108729.msg438281#msg438281 date=1158782054]
You need to stop thinking in absolutes and start realizing that there is a variety of ways to attack a problem and some may be better than what you currently use.
[/quote]

Actually I do that do a sickening extend. I tend to go so far that while I've a perfectly working solution I'll abandon it, just to try if something else might work better. Which isn't all bad, but makes creating an application a very time consuming process...

[quote]And one more thing... "sessions in all it's colors and flavors" doesn't make any sense either.  Sessions are sesssions.  It's an object.  How can it have more than one color or flavor?!?![/quote]

I was refering to both session layers in other protocols (FTP, SMTP, FTPS, Telnet, more) and the variety of possible implementations of session management in HTTP dependant applications.

That is what I'm trying to say. Took me long enough to write, phewey... :-[

I hope you see where I'm coming from now.  :)

[tomfmason]

So what should I do..

Shoud I go ahead and store users ip and a time stamp to identify the user?

[hr]
@448191

  In reponse to your first post.

  I think that it is alot more likely that I would have multipule refreshes and end up losing the session data then haveing multipul people on the same network with the same ip connecting at the exact same time.

[hr]

So I am thinking that I will go ahead and use the database idea.

Now what I think that i am going to do is store the ip and last action time (timestamp) in the db.

Now I will check to see if the users ip is in the database before the page loads. If it is not, then I will echo an onload in the body of the page and call a function like begin_chat ( or what ever.)

Now if the users ip is in the database then I will check the last action and if the time stamp is more then, say five minutes, I will make them reinstate the chat session.

Also, maybe I can check the status and if it is not waiting or chatting then I will make them reinstate the chat.

Does that sound like a feasible way of doing this?

Also, how exactly should I obtain the users ip. I think that the function is (Ajax) getRemoteAddr();. Correct or ??

Thanks again,
Tom

[448191]

[quote author=tomfmason link=topic=108729.msg438366#msg438366 date=1158792653]
In reponse to your first post.
I think that it is alot more likely that I would have multipule refreshes and end up losing the session data then haveing multipul people on the same network with the same ip connecting at the exact same time.
[/quote]

I'm not making this stuff up you know. You can not use IPs, for one they can change within the session.

[url=http://www.w3.org/TR/WD-session-id]W3C on session id's, skip to paragraph "Pseudo Session Identifiers". [/url]

Also, you shouldn't be losing session data after mulitiple refreshes. If that is what happens, fix your code.

[hr]

If you insist on using custom IP based session management (THAT is what your database idea is), the way to get the clients ip on the server is by $_SERVER['REMOTE_ADDR'].


For the record, since you're set on using a RDMS for storage (which is a good thing, I can recommend it), I would say the easiest solution is to define a customized 'save handler' using session_set_save_handler(). If you insist, you can avoid the session_* altogether, but then you will be responsable for handling caching, and an interface to fetch data.

[tomfmason]

Thank you both for the suggestions. I decided that I would use sessions in conjunction with the ip session management.

First I check to see if the session or cookie exists(a much faster method). If not then I go through the ip session management system to see if the chat session exists.


Thanks again,
Tom

[448191]

[quote author=tomfmason link=topic=108729.msg440031#msg440031 date=1159037265]
Thank you both for the suggestions. I decided that I would use sessions in conjunction with the ip session management.

First I check to see if the session or cookie exists(a much faster method). If not then I go through the ip session management system to see if the chat session exists.

[/quote]

LOL... Did you get the part where I said you can't use ips as id's?  :D

Fine, it's your app, not mine.  Do watever you like. :)

That second parapraph of yours doesn't make much sense too me.  ???

[tomfmason]

What would you suggest using as a client id then? Maybe point to some resources or an example. I am not trying to ruffle any feathers with this one but I am wanting to use sessions and some alternative method of identifying the client.


Thanks,
Tom