jiggs

You definitely don’t have URL Rewriting enabled properly. Please review Apache documentation on how to enable URL Rewriting. Once you make the change you must restart Apache.

Cheers.

@JeffAv No luck on my end yet. I'm going to try what @KevinTheJedi said and manually create the rules present in \osticket\api as rules in IIS. Please do let me know if you find a way around this.

rjkunde
Compare the default web.config file with your web.config file and ensure you have the following section in it under the <system.webServer> section

    <rewrite>
        <rules>
            <rule name="HTTP api" stopProcessing="true">
                <match url="^(.*/)?api/(.*)$" ignoreCase="true"/>
                <conditions>
                    <add input="{REQUEST_FILENAME}" matchType="IsFile"
                        ignoreCase="false" negate="true" />
                    <add input="{REQUEST_FILENAME}" matchType="IsDirectory"
                        ignoreCase="false" negate="true" />
                </conditions>
                <action type="Rewrite" url="{R:1}api/http.php/{R:2}"/>
            </rule>
            <rule name="Site pages" stopProcessing="true">
                <match url="^(.*/)?pages/(.*)$" ignoreCase="true"/>
                <conditions>
                    <add input="{REQUEST_FILENAME}" matchType="IsFile"
                        ignoreCase="false" negate="true" />
                    <add input="{REQUEST_FILENAME}" matchType="IsDirectory"
                        ignoreCase="false" negate="true" />
                </conditions>
                <action type="Rewrite" url="{R:1}pages/index.php/{R:2}"/>
            </rule>
            <rule name="Staff applications" stopProcessing="true">
                <match url="^(.*/)?scp/apps/(.*)$" ignoreCase="true"/>
                <conditions>
                    <add input="{REQUEST_FILENAME}" matchType="IsFile"
                        ignoreCase="false" negate="true" />
                    <add input="{REQUEST_FILENAME}" matchType="IsDirectory"
                        ignoreCase="false" negate="true" />
                </conditions>
                <action type="Rewrite" url="{R:1}scp/apps/dispatcher.php/{R:2}"/>
            </rule>
        </rules>
    </rewrite>

Hope that helps you.

rjkunde

You are having certificate issues (maybe self-signed cert or something). You need to follow the link in the error and look for possible resolutions.

Cheers.

The server has a valid Let's Encrypt cert. Verified w/ multiple browsers. Unclear why this error is happening. The links are to the libcurl docs, which state: The remote server's SSL certificate or SSH fingerprint was deemed not OK.

If I find anything I'll post more info.

Looks potentially related to not sending intermediate certs. Not sure if I have to set certificate paths in PHP, I thought ACME/Let's Encrypt handled it. Still looking.

Rebooted server, no change: invalid_client
Versions:
osTicket (v1.17-rc4)
Oauth2 Client 0.3
PHP 8.1.10
Windows Server 2019 Standard
IIS 10.0.17763.1

Not sure on phar or not, I didn't actually install the plugin, someone else did. I can confirm though.

Ah, the plugin is now on v0.6
Please update it and test again.

Thanks @mbanyard and @KevinTheJedi I'll try updating the client this afternoon and see what happens.

Swapping back to the old plugin doesn't resolve it. I'm going to replace all of the core files and start fresh.

rjkunde

No the oauth2 plugin isn’t merged yet so it’s a pull request:

• https://github.com/osTicket/osTicket-plugins/pull/231

Cheers.

KevinTheJedi This guide worked out for me. After a day's worth of struggle and fighting with everything from having the right PHP version installed all the way to getting a successful connection to outlook.office365.com's IMAP service (on port 993) via the Microsoft OAuth2 authentication (plugin version 0.5), I wanted to leave a few notes for the next guy that may be struggling with this:

1. If you're on PHP 7.x and osTicket 1.15.8, get PHP 8.0 working first. Specifically 8.0. Upgrade to osTicket 1.16.3 by copying the contents of the "upload" directory over the contents of the existing 1.15.8 installation. As in a folder merge, overwriting any existing files. Update your filesystem permissions as needed if you are doing this through WinSCP as root (www-data or whatever webserver user needs permissions)

2. Once you can verify that 1.16.3 is working (after going through the upgrade in the web interface) it's time to do the same thing with the 1.17 RC4 "upload" directory. Merge everything with the 1.16.3 installation overwriting all conflicting files. This is one of my many struggles. Apparently a fresh install of 1.17 RC4 does not work with the database still having data from 1.16.3? After that merge/copy/overwrite, be sure to update file permissions as needed.

3. Unsure how this goes on Windows servers but for my case in a Debian 11 install with apache2, I had to tell apache2 to read the .htaccess files and enable the rewrite module. In the apache2.conf file, there might be a few lines that say "AllowOverride None". Those lines need to read "AllowOverride all". You also need the rewrite module enabled, it's usually enabled via "a2enmod rewrite".

4. Follow this guide I am replying to exactly. (https://github.com/osTicket/docs/blob/3b6b623c026c15bb267e404a4afd72b19d29f035/OAuth2/Microsoft%20Authorization%20Guide.rst) Meaning create a new Azure app. I believe my issue was that I had created my Azure app a while back and something was different about the JSON that comes back from the user details "/me" endpoint.

Hi guys, we are now two days out from the Oct 1 basic auth cutoff, do we yet have a date for 1.17 stable release? Additionally when configuring in our environment, attempting to configure the OAuth2 plugin always requests admin consent, and never successfully configures. Is this a known issue? Cheers.