osTicket Version: v1.17 (1d8b790)
Web Server: Apache/2.4.38 (Debian)
Current Setup: [VM hosting osTicket] <> [Windows Server 2016 IIS] <> [CLIENTS]
I have osTicket running in a Debian VM, that I access via a reverse proxy through IIS. osTicket is set up via HTTP only, and I have a certificate set up on IIS that everyone accesses the site through. Up until trying to use OAUTH, I haven't had any issues. Unless specified below, all access to the site is via the reverse proxy, not direct.

After installing the OAUTH plugin, I had a really hard time trying to get login authentication working. I would click on the "Sign in with Azure" link, but it kept going to https://[my.domain.com]/{rest of URL} instead of https://login.microsoftonline.com/{rest of URL}. If I browsed directly to the VM, it worked as expected. I was able to determine that it was a rewrite issue, and after much searching, I found that I had to install the "Application Routing Request" application, and from there disable the "Reverse rewrite host in response headers" option. Now I can log in to osTicket via Azure.

Now I am trying to set up my e-mail via OAUTH. If I click on the Config button in the e-mail setup, all I get is a thin white box. It won't disappear until I reload the page.

If I access the site directly, clicking Config goes to the Microsoft login page, and upon entering in the e-mail account, it comes up to the "Approval required / unverified / This app requires your admin's approval" screen. I enter in the reason, and then I approve the request via my Azure admin account. However, even after approving the request, it keeps asking over and over for approval and doesn't go any further. Additionally, if I try using my Azure admin account to log in rather than the e-mail, I get the "Permissions requested / osTicket / unverified / This application is not published by Microsoft / Give Consent" form. Even after giving consent, it just goes back to the osTicket customer login page, and re-running the Config just starts over at square one.

Has anyone run into this particular issue yet?

  • KevinTheJedi replied to this.

  • themanbornwithin

    I was finally able to rectify this issue. I ran Fiddler (an awesome tool for diagnosing web sites, definitely worth a look) and found that IIS was throwing errors because of a colon in the URL (A potentially dangerous Request.Path value was detected from the client (:).) (The request was GET /scp/ajax.php/email/5/auth/config/mailbox/oauth2:msmail HTTP/1.1). I used the following in my web.config to bypass the colon, and success!!

    <system.web>
    <httpRuntime 
        requestPathInvalidCharacters="&lt;,&gt;,*,%,&amp;,\,?" />
    </system.web>

      themanbornwithin

      You will need to either lift the restriction so users can consent themselves or you will need to customize the plugin to remove the prompt=consent option. For that you will need to download the raw plugin files, hydrate the plugin, make the changes and replace your current plugin with the customized one.

      Cheers.

        Unfortunately giving users the ability to consent on behalf of the organization does not work. It still goes as follows:

        Access osTicket site via IP > Email > Config > Fill out Microsoft login > Accept Permissions > Goes back to osTicket Main Page via Proxy URL

        I was able to successfully configure an e-mail account by brute force.

        -I connected to the site via IP
        -I changed the Redirect URI to the IP of the server using HTTPS (which isn't configured on the server)(https://0.0.0.0/api/auth/oauth2)
        -I added the URL to Azure
        -I went through the config process. When it returns, the page fails to load due to not having HTTPS on. I changed the URL in the browser to HTTP, and it uploaded the token to osTicket
        -osTicket imported the pending mail

        How can I help the developers rectify this issue?

          Unfortunately it seems like my luck didn't last. The e-mail did not pull a new token, and I am no longer able to pull e-mail into osTicket.

          It has to be some sort of rewrite issue, but I'm not sure where to look?

          8 days later

          themanbornwithin

          I was finally able to rectify this issue. I ran Fiddler (an awesome tool for diagnosing web sites, definitely worth a look) and found that IIS was throwing errors because of a colon in the URL (A potentially dangerous Request.Path value was detected from the client (:).) (The request was GET /scp/ajax.php/email/5/auth/config/mailbox/oauth2:msmail HTTP/1.1). I used the following in my web.config to bypass the colon, and success!!

          <system.web>
    <httpRuntime 
        requestPathInvalidCharacters="&lt;,&gt;,*,%,&amp;,\,?" />
    </system.web>
            14 days later

            will01158

            Make sure you install v1.17.1 AND the new OAuth2 plugin. The changes are mainly in the Plugin so this part is very important.

            Cheers.

              a year later
              16 days later
              Write a Reply...