Session Cookies

edited July 2013 in Enyo 2
I'm connecting to a Nodejs REST server locally (cross domain allowed). Authentication is being managed using a session cookie module. Using simple HTML and AJAX calls everything works great. From Enyo though, I can see the set-cookie coming in post login, but subsequent requests are not including the cookie. Doesn't look like the cookie is getting created (Firefox or Chrome). Also tried running Chrome with
but no difference, still not seeing the cookie.

Various threads here discuss issues with Enyo and trying to access cookies and local storage. But I'm serving up the Enyo from a local server, shouldn't the browser take care of the cookie for me?

If not, what's the solution. I already tried turning off the httponly flag, but the
comes up empty.

Follow up question would be what's the generic solution that would work running as a packaged app or served from a web server? Do I have to use something other than cookies?


  • edited July 2013
    So I found a discussion on the Palm forums here. According to this (and as I believed) I shouldn't be having an issue. The discussion explains that Enyo behaves just like a web browser. The remote server creates the session cookie, which should be sent on subsequent Ajax requests.
  • edited July 2013
    So according to this discussion, I need to turn on credentials to get cookies included on requests. I can do this easily by adding this attribut to my enyo.AJAX kind
       xhrFields: {
          withCredentials: true
    This seems like it should be unnecessary, but okay. The next problem is the Access-Control-Allow-Origin: '*' isn't allowed with credentials. So I fixed that, now requests originating from my Enyo server are hitting my Nodejs REST server and still getting denied????

    Here's a request header
    Request URL:http://localhost:3000/api/v1/session/login
    Request Method:OPTIONS
    Status Code:500 Internal Server Error
    Request Headersview source
    Access-Control-Request-Headers:origin, content-type
    User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
    Response Headersview source
    Date:Wed, 10 Jul 2013 15:04:28 GMT
    And the error in the console:
    XMLHttpRequest cannot load http://localhost:3000/api/v1/session/login. Origin http://localhost:8888 is not allowed by Access-Control-Allow-Origin. 
    Now what?
  • edited July 2013
    Hi, this looks like a CORS issue. I had something similar where IE9 sends an OPTIONS request to know what types of methods are allowed prior to actually doing a call. I changed the server code to return a valid response if OPTIONS was sent. Can you get your Node.js session to respond to the OPTIONS with a list of methods: e.g.
    if (request.getHeader("Origin") != null) {
                response.addHeader("Access-Control-Allow-Origin", request.getHeader("Origin"));
                response.addHeader("Access-Control-Allow-Credentials", "true");
                if (request.getMethod().equals("OPTIONS")) {
                    response.addHeader("Access-Control-Allow-Methods", "GET, HEAD, PUT, POST, DELETE, TRACE, OPTIONS");
                    if (request.getHeader("Access-Control-Request-Headers") != null) {
                        response.addHeader("Access-Control-Allow-Headers", request.getHeader("Access-Control-Request-Headers"));
  • I started down this path yesterday. I didn't try the OPTIONS yet, but I'm not sure it will come into play for my POST. The frustrating thing is the Node server processes the request, the failure occurs sending the response. I'm using Restify and overrode the preflight method, all I've accomplished is seeing different errors.

    I thought it was my Ajax, but now realize something's up with the server. I'll have to check the restify forums, or maybe switch to a different server.

  • edited July 2013
    So the solution (almost anyway) involves both the server and the Ajax. There is a good npm package (se7ensky-restify-preflight) that sets up the server request pre-processing to accept credentials.

    But I was also trying to set the credentials flag with xhrFields, and seemed to get past the OPTS call and fail on the subsequent POST.
      , kind: 'enyo.Ajax'
      , xhrFields: {
          withCredentials: true
    Changed it to this, and it works IF I disable Chrome web security with the --disable-web-security flag.
      , kind: 'enyo.Ajax'
      , headers: [{'Access-Control-Allow-Credentials':true}]
    The OPTS and POST look correct, but Chrome is still preventing the Set-Cookie coming back from actually storing the cookie.

    If Chrome and Firefox are locking down this feature, what is the correct alternative? Or will mobile apps running Enyo be okay? Or I guess some platforms will require the app package to declare secure access to resources? For example Firefox OS, an app might have to be declared as 'priviledged' in the manifest.
  • edited August 2013
    Turns out
      , xhrFields: {
          withCredentials: true
    is the correct solution, my server was handling the OPTIONS request correctly but not the POST. Drove me nuts until I finally went through the server code line by line and found that I had the preflight code in two places and configured differently.
  • Thanks, the xhrFields flag solved an issue for me too.
  • hello @pcimino, @MarinaEariel ,
    can you send me your login code function, i don't know how to use session or cookie in enyojs for webOSTV.

    Thank you so much.
  • @tienn2t Unfortunately, you can't use session cookies in a web app on webOS TV.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!