Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 21 total
Thread Sessions
Fri, Aug 7 2015 7:15 AMPermanent Link

squiffy

Telemix Ltd.

Avatar

I'm having trouble getting my head around this one ...

I have an API server that uses session data. If I access the page directly from the browser, everything works fine. The session id is the same between requests and all my logic is good.

From within the EWB app I access this same page using ServerRequest. For testing purposes I have the execute attached to a button.

If I run the app in the IDE and click the button to perform the server execute, everything works fine. The session id persists as desired.

But if I run the EWB app directly in the browser it creates a new session id on every request. Tried on FF, Chrome & IE. This is not desired for obvious reasons.

Any suggestions, anyone? Driving me bonkers.

Thanks.
Fri, Aug 7 2015 7:28 AMPermanent Link

Walter Matte

Tactical Business Corporation


>>But if I run the EWB app directly in the browser it creates a new session id on every request.
>>Tried on FF, Chrome & IE. This is not desired for obvious reasons.


What do you mean - "directly in the browser"?

The session needs to come from the Web Server  - so if you just load the page from a file on disk and not being served up from the Web Server, I don't think that can work.

I'm not an expert here, others please correct me.....

Walter
Fri, Aug 7 2015 7:55 AMPermanent Link

squiffy

Telemix Ltd.

Avatar

I am pointing the browser to the EWB server (eg http://localhost:8881/testproject.html)

Potentially relevant info - I am running a Jetty server for the API and the EWB IDE all on the same laptop, but on different ports.
Fri, Aug 7 2015 8:02 AMPermanent Link

squiffy

Telemix Ltd.

Avatar

Just to be clear, there were two "directly in the browser" references. The first was relating to the API server, the second to the EWB application. The explanation above was actually relevant to both. In the first I pointed the browser to the API URL (localhost:8550/api) and in the second to the EWB app URL (localhost:8881/testproject.html). The EWB app calls the API URL using a serverrequest. Hope that's clearer.
Fri, Aug 7 2015 9:29 AMPermanent Link

Walter Matte

Tactical Business Corporation

squiffy wrote:

Just to be clear, there were two "directly in the browser" references. The first was relating to the API server, the second to the EWB application. The explanation above was actually relevant to both. In the first I pointed the browser to the API URL (localhost:8550/api) and in the second to the EWB app URL (localhost:8881/testproject.html). The EWB app calls the API URL using a serverrequest. Hope that's clearer.


The issue is Browser Security.

https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

The browser will not allow this.

Walter
Fri, Aug 7 2015 9:49 AMPermanent Link

squiffy

Telemix Ltd.

Avatar

Not sure how that relates, please can you explain? I do struggle with web stuff like this.

Each AJAX request is being received and processed by the API server, and any result is being sent back to the browser which is displaying it fine. There are no cross site scripting errors as I have the correct header set in the response (removing this header does cause cross site scripting problems).

So the issue is not that I cannot get an AJAX request to complete its round trip and display the result in the browser; I can. The issue is the session persistence.

The server sees each request as new from an external browser (on the same PC), but NOT from the EWB built in browser, which works exactly as required.

If I skip the EWB application and point my browser directly at the API server URL, then that also works fine, which in my head says that the browser has no issue with the session/cookie storage per se.

I agree its probably a permissions thing, but I just cannot see what. The working in the EWB internal broswer but not an external browser is the thing that is throwing me particularly.
Fri, Aug 7 2015 10:03 AMPermanent Link

Walter Matte

Tactical Business Corporation


It works in EWB, because Tim allows it - so we can test.

But in the real world you are accessing two servers. (two ports)  Cross Origin.  

I am not an expert here either, but I believe you can set Header to permit CORS


http://www.w3.org/wiki/CORS_Enabled


Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: http://example.com:8080


If you search the forum "Access-Control-Allow-Origin" I believe there are threads on this topic.

Walter
Fri, Aug 7 2015 10:17 AMPermanent Link

squiffy

Telemix Ltd.

Avatar

As I say, I've done all of that and there's no cross site scripting errors with the header set, so whilst it may somehow be related it's not directly that.

Anyone have any other ideas?

Thanks all.
Fri, Aug 7 2015 10:21 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

<< The session id is the same between requests and all my logic is good. >>

Are you responsible for providing the session ID with each request ?  Or is it being returned as a response ?

<< But if I run the EWB app directly in the browser it creates a new session id on every request. Tried on FF, Chrome & IE. This is not desired for obvious reasons. >>

F12/Network would be where I would start here.  See what's going back and forth over the wire.

Tim Young
Elevate Software
www.elevatesoft.com
Fri, Aug 7 2015 10:23 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

<< Each AJAX request is being received and processed by the API server, and any result is being sent back to the browser which is displaying it fine. There are no cross site scripting errors as I have the correct header set in the response (removing this header does cause cross site scripting problems).

So the issue is not that I cannot get an AJAX request to complete its round trip and display the result in the browser; I can. The issue is the session persistence. >>

Do you know if the HTTP responses from the web server are trying to set a cookie containing the session ID ?

Tim Young
Elevate Software
www.elevatesoft.com
Page 1 of 3Next Page
Jump to Page:  1 2 3
Image