drupal.userLogout doesn't succeed.

[webdobe]

Not sure at this point what is going on. All my other app calls work but when I call logout there is no response.

Running D8. There is also some redirect action going on after the logout call. Which I think is because my "frontpage" is set to "user".

[signalpoint]

@webdobe Please provide more context from your Network and/or Console tabs to show the request/response in more detail. We're looking for headers/payloads/status-codes/responses/etc.

[webdobe]

When calling jdrupal.userLogout(); I get a status code: 0 and no statusText. It doesn't look like jdrupal uses the logout_token (that is returned during the login request), does that matter with the introduction in 8.2.x? All other requests are working normally at the moment.

[signalpoint]

@webdobe This is how logout is working for me in jDrupal 8:

GET: http://example.com/user/logout
Status Code: 302 Found

There are no tokens needed in the header AFAIK (since it is a GET call). Now that I am revisiting this, I see the logout functionality is pretty cheap in jDrupal, since all it is doing is make a call to /user/logout on the Drupal website, it's not utilizing REST in any way. It is working properly for me, it's just kind of cheap how I implemented it. This is for Drupal 8.2 for me as well, it seems to be working fine.

The 302 would explain the redirect to the front page that you have noticed, but my actually web app doesn't redirect, it safely logs out.

I do now see the logout_token you mentioned being returned in the login response, but at this point I'm unsure of how/when to use it.

[webdobe]

If your getting 302 how does it pass the validation in logout? The code says 200 and 303. Doesn't seem to fix my issue but... Just curious.

[signalpoint]

If your getting 302 how does it pass the validation in logout?

@webdobe I think because it is running through an XHR, and just the simple action of visiting the user/logout like you would normally in a browser (but it's happening via XHR and GET) fires the user logout event in Drupal, clears the sessions/cookies/etc, and then when the redirect happens, the end user doesn't actually see it because it's running through the XHR.

All in all, it sounds like we need to figure out a proper call to the user logout rest resource in D8.

And you're right, it's odd that the code is only allowing for 200 and 303: https://github.com/easystreet3/jDrupal/blob/8.x-1.x/src/includes/rest.inc.js#L127 - I can't remember why I added the 303 there, but maybe we can add the 302 there, does that work for you? Thoughts?

[webdobe]

I am still debugging.. I am still only getting a status code of 0 which doesn't help with anything... I am looking into this: http://stackoverflow.com/questions/16386148/why-browser-do-not-follow-redirects-using-xmlhttprequest-and-cors/20854800#20854800 which is just another CORS issue so probably nothing really wrong with this.

[webdobe]

So that is what it was... With my dev setup where I am sharing creds on different domains ie localhost and example.com. I think it may be the same for xxx.example.com and example.com. I believe browsers follow that 3xx request... Which was following to the home page which kicked a 403 forbidden..... Not sure why. I removed the sites Default front page... and the logout worked... So something with CORS and redirect... makes things no so fun.

I ran into a similar thing with d7 and the triggers module. When a trigger was setup to redirect after login.

I found this:

Investigation of the problem showed that his XHR was not landing on the CORS-enabled URL directly, but was being redirected to it through an HTTP 302 (redirect) response.

So bear in mind that the redirecting URL must also include an Access-Control-Allow-Origin header, else the browser will stop right there with its attempted cross-domain request.

I wonder if this is a bug in drupal core.

[kentr]

@jesse if this problem is only happening on your dev box and is indeed CORS, and you don't want to monkey with the Drupal-side CORS settings, you can use the Google plug-in to disable it while you're doing dev to bypass CORS.

…

On Dec 13, 2016, at 12:07 PM, Jesse ***@***.***> wrote: So that is what it was... With my dev setup where I am sharing creds on different domains ie localhost and example.com. I think it may be the same for xxx.example.com and example.com. I believe browsers follow that 3xx request... Which was following to the home page which kicked a 403 forbidden..... Not sure why. I removed the sites Default front page... and the logout worked... So something with CORS and redirect... makes things no so fun. I ran into a similar thing with d7 and the triggers module. When a trigger was setup to redirect after login. I found this: Investigation of the problem showed that his XHR was not landing on the CORS-enabled URL directly, but was being redirected to it through an HTTP 302 (redirect) response. So bear in mind that the redirecting URL must also include an Access-Control-Allow-Origin header, else the browser will stop right there with its attempted cross-domain request. I wonder if this is a bug in drupal core. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[webdobe]

Well I build apps often that go from subdomain and connect to the main domain. So I need to get a good grasp of overriding cors.

session.storage.options:
    ...
    cookie_domain: '.app.example.web'
cors.config:
    enabled: true
    # Specify allowed headers, like 'x-allowed-header'.
    allowedHeaders: ['*']
    # Specify allowed request methods, specify ['*'] to allow all possible ones.
    allowedMethods: ['*']
    # Configure requests allowed from specific origins.
    allowedOrigins: ['http://app.example.web', 'http://localhost:9000']
    # Sets the Access-Control-Expose-Headers header.
    exposedHeaders: false
    # Sets the Access-Control-Max-Age header.
    maxAge: false
    # Sets the Access-Control-Allow-Credentials header.
    supportsCredentials: true

Then make sure your page doesn't redirect after login or logout and or redirect after any of your requests in general... and everything seems to work.