RTC Forums
April 27, 2024, 08:29:16 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Identify Session  (Read 5316 times)
ithuman
Guest
« on: March 14, 2010, 11:45:44 PM »

Hi Guys

I'm trying to make a webserver using the httpdataserver and dataprovider.
what i Can't do is how to identify each session so i can handel its state and its own variables.
i tried opensession in onconnect event but when handeling the ondatarecieved of the dataprovider how i determin the session ID??

any ideas??
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #1 on: March 15, 2010, 01:00:08 AM »

Forget OnConnect. The only events you need are OnCheckRequest, OnDataReceived and OnDataSent on the TRtcDataProvider component. There are actually a number of examples which show you how to use RTC Sessions, all spread in different RTC Articles and Demos, but for a quick start I recommend you to take a look at this one.

Also, if you have not done that already, I strongly recommend you to go through the RTC SDK Quick Start examples. Not just fly them over, but actually try them out to get the basics.

Best Regards,
Danijel Tkalcec
Logged
ithuman
Guest
« Reply #2 on: March 15, 2010, 11:33:15 AM »

Thanks Danijel,
That was helpful, but may i didn't explain my problem well. I used to identify the diffrent sessions using peer address and peer port and it worked good.

However when the session is opened using diffrent tab using IE7+ it uses the same peeraddress and same peer port.

So i tried the sessions of RTC library. Now I'm facing the same problem again after i used it.
when i open different tab in the IE browser it uses the Cookie and same session ID.

what can i do?



Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #3 on: March 15, 2010, 11:54:35 AM »

Using Peer Address and Port is a very poor method for identifying users and will NOT even work if your users are behind a Proxy, because you will only see the Address and Port number of the Proxy connecting to your Server. To make things even worse, depending on the Proxy or Browser implementation, the exact same user can connect to your Server using multiple physical connections, which means that you will see different Port numbers for the exact same user. Thinking that this means the user has opened a new web page or a tab is just plain wrong.

When you generate the HTML for the Browser, you have to include enough information for the Server to be able to identify the user when it comes back to the Server after clicking an URL on the page or submitting data. You can do this by using Cookies, or by embedding users Session ID in URLs you include in the HTML generated and sent to the Client.

I do not know why you want to know if a user has opened the same URL inside the same Browser in a separate Tab, but I do not know of any reliable way of knowing whether the user has copied the URL and used it in a separate Tab, or if the user has simply refreshed the page. And I seriously doubt you want to start a new session if a user refreshes the page. Especially since refresh might be necessary if the user did not receive the complete response (for example, connection broke after you've sent the response, but before the last packet received the user).

What is your actual situation? Can you explain what is it exactly you want to achieve? Why do you want to see the exact same user as different users if the user opens the same URL in a separate tab inside its Browser?

Best Regards,
Danijel Tkalcec
Logged
ithuman
Guest
« Reply #4 on: March 15, 2010, 12:09:37 PM »

Hi Danijel,

What i want to do is a webserver that integrate with Oracle EBS. The user will authinticate with same user and password on the Oracle server. So in my web srver i have to keep track each session and its state and its user name.

This is working fine till now as long as the user opens a different browser. for many reasons same user may open many sessions with different responsibilities ( wither same user name or different user name as example sysadmin and workflow admin) and work on different data at same time. and so he need to open two or more different browsers. Some times he open diffrent tab instead of different browser, that's why i need to know if he opened different tab.

In the current solution when the user try to open diferent tab it's automatically filled with the original data since the browser sent the same Cookie and session Id to the server.

if this is hard to achieve i will go on and consider this as minor limitation for my web server.




Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #5 on: March 15, 2010, 12:28:58 PM »

This has nothing to do with the Web Server nor the RTC SDK. If the Client chooses to copy/paste the URL and use it from a different Browser or a different Tab inside the same Browser, the Server can end up receiving the exact same data from the Client as if he was refreshing the page. The Server will simply get a new request for the same URL. How you handle that situation is entirely up to you.

Another thing you need to consider is whether you really want to use Cookies. I know it is tempting to use Cookies because they will somewhat reduce the size of the HTML you are sending to the Browser, but I think you will be much better off if you would embed the Session ID inside the URL (which you will get as a request Query parameter in the RTC SDK).

By NOT using Cookies and by embedding Session IDs in your URLs linked from the page displayed AFTER the user has logged in, will have two positive effects: First, your Server will be working with Browsers which have Cookies disabled (a lot of companies disable Cookies for security reasons) and Second, the user will NOT automatically end up being logged in if he opens a new Tab inside its Browser and manually enters the URL to your Server.

By NOT using Cookies, you could also try to hide the full URL from your users by embedding the actual URL they are on by using <iframe>. That way, even if the user would want to copy/paste the URL, most will only end up on the login page when they open a new tab even if they would copy/paste the URL displayed on their original tab. But ... some browsers might NOT support <iframe> or might disable the use of <iframe>'s for security reasons, and ... some users might simply use the right-click pop-up menu and select "Open Link in a new Tab" to open the next URL inside a separate tab, in which case even an <iframe> will not help you.

Best Regards,
Danijel Tkalcec
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #6 on: March 15, 2010, 12:49:36 PM »

But ... if you write your Server side code correctly, which means that you will include enough information in the URL for your Application to know what the user wants to see next and NOT make assumptions about what the user might want to do next based on the last page he has visited, I do NOT see why it should be a problem for you even if the user should have multiple windows or tabs open to the same application.

The RTC SDK will make sure that the same Session can NOT be locked from two users at the same time, so you do NOT need to worry about concurrent access to the same Session data. But what you want to do when a request comes in and the Session was found is entirely up to you. The RTC SDK will give you the complete request data it gets from the Server and you will prepare the complete response.

If your application is currently having problems when the user opens the next URL in a new tab, you might want to reconsider how you have implemented navigation between your pages.

Best Regards,
Danijel Tkalcec
Logged
ithuman
Guest
« Reply #7 on: March 15, 2010, 01:12:06 PM »

Hi Danijel,
Thanks very much for that rich discussion about using cookie

that was real nice from you to be informative like that.
I already tried the cookie and it worked nice (except for the tab issue) but after your discussion i will consider not using it.
At the end there is still no way to distinguish between two tabs in same browswer and as I said it will be very minor limitation.


Thanks again
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.025 seconds with 16 queries.