Action not allowed when logout

[red-ruby-quay]

Thanks for your plugins, It works for me,

This is due to SSO Logout. I'm using keycloak as idp, and using idp logout parameter as the link for SLO request. The problem is, when I logout the account that successfully logged in, the redirect goes to {{url_base}}/plugins/phpsaml/front/slo.php and displayed this error page. But the post binding for the logout seems worked

I think the cookies and the session has been destroyed while the route redirected to .../front/slo.php, so the access to that route is not allowed.

Could you check the logic flow and fix that error? So when the user logout, the session and cookies expired and only redirected to the login page again, not to the slo file.

Btw, I had change the url of SSO on phpsaml.class.php (line 88) so it could redirect to base url or login page. But nothing happened...

[DonutsNL]

Im not sure SLO is used. It simply performs a die() after loading the glpi includes. As far as im aware, the file has never been hit in any of the setups i know.

Please try to redirect the user to the glpi index page instead.

[red-ruby-quay]

No, I've use SLO as the logout request. But as you could see, still redirected to the SLO link itself even after the cookies and sessions deleted.

and what I knew before, there is no die() performed after loading glpi includes in phpsaml.class.php

I've tried to change the redirect link (in picture 1), but nothing happened, still error redirect even the request status is OK 200.

Could you tell me what to do and what file that I must change the code to take the correct redirect result?

[DonutsNL]

Im not sure what i am looking at in the first screenshot. I do recognize the second screenshot. Looking at the current master branch (of our code), the slo is performing a die(); basically not doing anything atm. As you can see for yourself.

What version of phpsaml are you using currently, and can you share the slo.php with me?

[red-ruby-quay]

I'm sorry for the super late respons... I use the latest version of this project (tag 1.2.1, master branch)

This is the slo.php

[red-ruby-quay]

I'm sorry for the super late respons... I use the latest version of this project (tag 1.2.1, master branch)

This is the slo.php

What do I do? I mean like delete the die(); code and just redirect it to login page auth()->login();?

[ChrisGralike]

You could indeed try to remove the die() statement. But the logic following doesnt realy make sense to me. My advice would be to simply copy paste rules 21 and 22 before the die();. With a little luck (i have not reviewed and tested this logic) this will redirect the user back to the index as intended. The simpler solution would be to simply redirect back to the index page from the idp.

[red-ruby-quay]

Thanks for the advice.. I've managed to get in how to logout without stuck in {{server_url}}/plugins/phpsaml/front/slo.php "not allowed method". My SP use this url for redirection to index page, because of the name and the plugin told us to set the slo link. But it was failed because this file (slo.php) basically doing nothing...

Here's my code on slo.php (replacing all codes)

<?php
 /* Redirect browser: change the location based on latest server deployment place, no need to change 'true' value for default header replacement and default response code (302)*/ 
header("Location: {{your_base_url}}"); 
/* Make sure that code below does not get executed when we redirect. */
exit;
?>

It is pretty simple, but you could modified it anything you want...

I've tried @ChrisGralike advice that "21 and 22" rules must be used. But it couldn't, because the session has already been cleared while the code try to use some of onelogin saml library for another authentication process again. Instead you could use this code => plugins/phpsaml/front/ssoRequest.php but with some modifications (redirect to SLO then to base url instead of login redirect).

For anyone that couldn't know how to fix this slo bug yet (or maybe you could call it undone codes page...), try my advice in this comment. Make sure to share your accomplishment in this comment issue section for knowledge sharing and better improvement.

Anyway, thank you very much @ChrisGralike @DonutsNL !!!