Logging out of wordpress doesn't log out

[eauchat]

trafficstars

I don't know if the issue is related to the wordpress app specifically or to yunohost in general, since I have similar issues with other apps (or maybe they are different, but anyway). The issue is that if I'm logged in wordpress and click logout in the wordpress interface, I'm redirected to the sso login page, but if I open the administration url again, I'm still logged in.

My setup is wordpress single site with url: wp.domain.tld, and main yunohost domain is ynh.domain.tld.

[kay0u]

That's weird, I can't reproduce the issue on my side.

[eauchat]

Yes indeed, me too I can't reproduce it anymore, I wonder what was the specific situation when it happened. Could be that it was related to the error in #131 but I don't think so. I will close this for now, and reopen it with more details if it ever happens again.

[merchmanager]

Facing same issue. The issue happens when the logout link has a wpnonce attached to it, at which time yunohost takes over and redirects it to sso. But since the user is not a yunohost user, the login page is thrown up. If you copy and paste the URL without the wpnonce, it logs out all right. All in this thread need to test by logging in using a non yunohost account like a customer would.

i believe something is happening in the below code thats showing this behavior, but i am not an engineer and so not enough knowledge to fix.

(/usr/share/ssowat/access.lua)

– Get request arguments uri_args = ngx.req.get_uri_args()

-- Logout is also called via a `GET` method
-- TODO: change this ?
if uri_args.action and uri_args.action == 'logout' then
    logger.debug("Logging out")
    return hlp.logout()

-- If the `r` URI argument is set, it means that we want to
-- be redirected (typically after a login phase)
elseif is_logged_in and uri_args.r then
    -- Decode back url
    back_url = ngx.decode_base64(uri_args.r)

    -- If `back_url` contains line break, someone is probably trying to
    -- pass some additional headers
    if string.match(back_url, "(.*)\n") then
        hlp.flash("fail", hlp.t("redirection_error_invalid_url"))
        logger.error("Redirection url is invalid")
        return hlp.redirect(conf.portal_url)

[merchmanager]

Yes indeed, me too I can't reproduce it anymore, I wonder what was the specific situation when it happened. Could be that it was related to the error in #131 but I don't think so. I will close this for now, and reopen it with more details if it ever happens again.

you cant reproduce this because when you were thrown the yunohost login, you loggedin. Try opening an incognito page and login to wordpress and then click the logout button, same issue will come up. The website users will not be able to log in to yunohost login page and so they will never log out.

[eauchat]

@merchmanager From what I understand of what you describe, it seems like a different situation than what I had, but your description make some sense, do you think we should reopen this issues @merchmanager and @kay0u?

[merchmanager]

@eauchat If the issue can be reproduced, we should open it. I am not an engineer, but after having spent considerable time trying to grapple with the issue, my gut feel is that The root of the issue is the way logic for redirect is written for nGinx in config and access_by_lua files. It is also not considerate of redirects using CDN like cloudflare or an SMTP relay service like sendgrid. The logic essentially is that if you see some keywords in URL or get a URL which is 404, just redirect to SSO. To reproduce TYPE-A (1) Install wordpress in yourdomain.TLD/Home/ or any such folder (not root) (2) Set up proxy by using cloudflare DNS (free service) (3) Try logging out. TYPE-B (1) Install wordpress with woocommerce (2) Use Sendgrid SMTP relay service (free) for mailers (3) Enable campaign measurement in sendgrid (sendgrid will change the url structure in mails) (4) These campaign links will start throwing up yunohost SSO pages.

[eauchat]

@merchmanager It seems that the issue you're describing about the SSO are related more to the core of yunohost rather than to the wordpress_ynh package. I wonder if the way you understand the issue may explain some similar issues I've encountered with other yunohost packages like rainloop. I don't know, it's going beyond what I'm able to understand at the moment, but maybe it's a good way to investigate.

I didn't try the options you propose though, because they involve some services I don't want to have to subscribe to, and also because I don't think I can help much in resolving this issue. Sorry for that.

I'll reopen the issue since you ask it, and leave it to other contributors to investigate your suggestions if they have the time for it, maybe they'll be better help than me :)