Hi, I started to enable OAUTH2 for Office 365. I received the "file not found" error in the last step and then noticed that I need to modify my NGINX config. Did that change.

Problem is now that I can't open the authentication settings page again. If I click on "config" button, nothing happens. I already tried to reset the plugin data, change to basic authentication, reverted my NGINX settings etc.

Nothing brings the authentication page back.
What else can I do now?

Regards
Martin

    Not possible, checkbox is disabled. Already tried that.

    tinus

    Then you will need to clear some records in the database. Go to the email_account table, set auth_bk = NULL and auth_id = NULL. You'll then have to reconfigure the information of course.

    Cheers.

      Will give it a try and report back, thanks.

      The authentication selection is now empty. I can again select "OAuth2 - Microsoft". The "config" button turns into orange. But a click on config does NOT show the config window.

        tinus

        There are more logs than just system logs...(general server logs, webserver error logs, PHP error logs, MySQL/MariaDB error logs, osTicket System Logs, Browser Console logs, etc.)

          nginx logs says
          400 POST /scp/ajax.php/email/1/stash HTTP/2.0

            tinus

            That doesn't tell us much of anything other than that was a failed request. Do you have the appropriate NGINX rules? You can look at previous threads for people posting their working NGINX rules.

            Cheers.

              I have reset my nginx modifications but page does still not appear (only to be sure that my changes have not introduced the problem),

              I have added this part

              location ~ ^/api/(?:tickets|tasks|auth).*$ {
              try_files $uri $uri/ /api/http.php?$query_string;
              }

                tinus

                Then you will need to search for the working config from other community members or keep debugging to see if there are any relevant errors with more information.

                Cheers.

                  My problem is not my nginx config. It's back to default.
                  My problem is that I can't modify the authentication settings any more.

                    tinus

                    You are saying the Config popup isn't appearing. The popup uses AJAX. AJAX requires NGINX rewrite rules. If the popup is not appearing then you either have a fatal error being logged somewhere or the rules are not correct. Or maybe even borked codebase (like missing files, copy/replace didn't work fully, etc.).

                    Cheers.

                      I'm running osTicket on Plesk with nginx as proxy in front of apache.
                      Plesk somehow damaged the config files. I have now restored my configuration from backup and the button is working again.

                      However I'm now back to the callback issue. I get a valid token but the callback gives me "URL not supported".

                      My nginx rule looks like this

                      location ~ ^/api/(?:tickets|tasks|auth).*$ {
	try_files $uri $uri/ /api/http.php?$query_string;
}

                      That seems to work, because the log shows it's redirected to /api/http:
                      93.219.167.161 - - [27/Jan/2023:14:37:31 +0100] "GET /api/http.php?code=0.AV0Aw...-af7e-92ed872a25a6 HTTP/1.0" 400

                      What I'm missing?

                      Regards
                      Martin

                        tinus

                        Do you see any other relevant errors in your logs (general server logs, webserver error logs, PHP error logs, MySQL/MariaDB error logs, osTicket System Logs, Browser Console logs, etc.)? 400 doesn't tell us much.

                        Cheers.

                          Checked all, no php errors, no db errors, no browser errors, no osTicket errors.

                            tinus

                            Doing a quick google search says that your server is denying the request because Some common causes of the 400 bad request error are: Malformed URL syntax – the URL may contain invalid characters such as {, }, [, or ].. Seems NGINX is causing more issues than what it's worth. You should really use a supported webserver like Apache/LiteSpeed/IIS.

                            Cheers.

                              Write a Reply...