token expired with OAuth2: Page 2

token expired with OAuth2

ramrajone

osticketnoob22
Microsoft have hard shutdown older protocols starting in January, some tenant protocol was still being used in the backend
You can check if your tenant device(s) is still trying to use:
https://howtohelpdesk.com/how-to-get-basic-authentication-azure-ad-sign-in-log/

osticketnoob22

KevinTheJedi

For "next release and builds of plugins" is that something like a v17.3 osticket update or just a plugin revision? Or, "yes," both, a new osticket update along with a new plugin for this issue?

KevinTheJedi

osticketnoob22

Both core release (v1.17.3) and new builds of plugins.

Cheers.

fa1rid

KevinTheJedi I'm facing same issue with Google Cloud. Is it also because of the bug in the plugin?

KevinTheJedi

fa1rid

Do you see the same fatal errors in your logs?

Cheers.

fa1rid

KevinTheJedi

MikeIce

SOLVED -

After I've tried everything I found on the entire internet to prevent token from expiring, and nothing helped... finally I decided to quit WAMP or IIS and try osTicket on XAMPP.

GUYS THIS IS IT!

Stop your WAMP or IIS server.
Install XAMPP 8.0.28 / PHP 8.0.28 (https://www[dot]apachefriends[dot]org/download.html)
Install osTicket Core, v1.17.4 on XAMPP or Copy your osTicket files to XAMPP virtual servers folder and Import database to XAMPP MySQL.
Change your Cron Job paths with the new paths from XAMPP PHP and cron.php.

THATS IT! NO PROBLEMS WITH TOKEN EXPIRATION ANY MORE!

Possible explanation..

XAMPP comes with a SINGLE PHP and not with multiples as WAMP
Some Security Headers on WAMP or IIS may prevent token renewal.

It really works. Quit WAMP or IIS and use XAMPP, and thank me later.. 🙂

marriaza

The steps taken to address the issue: reinstall the plugin and recreate the email account configuration.

Back up the application.
Capture screenshots of the email account configuration for future use.
Download Oauth2 plugins from the official site for your version.
In Plugins > Oauth2 Client,
a. Instances: Delete the instance pointing to the email.
b. Go back to the Plugin tab; Change the status to Disable.
In Installed Plugins, remove the Oauth2 Client Plugin.
In the include/plugins folder, locate the auth-oauth2.phar file and delete it.
Paste the newly downloaded plugin file into include/plugins.
In Plugins, add it again.
Go to Emails, Settings; change the default system email to another one.
In Emails; Select and Delete the problematic account configuration.
Add the email account again (refer to the screenshots from step 2).
a. Account: Enter the account details,
b. Remote Mailbox: Configure OAth2 – Microsoft; re-enter Info, idP Configuration
c. When sending the data, Microsoft email account will prompt you for authentication; it ends here as you will receive the token in green.
d. Finish configuring the remaining settings.

ChrisAnders

We've experienced the same issues descried above with the refresh failing periodically. Normally, going into the "Token" tab of the Oauth2 screen and hitting Submit resolves the issue. You are forced to log into microsoft and reauthorise by ticking the consent on behalf of the organisation and then it all works. However, now, after ticking the consent box and saying Accept i get an error page saying:
The requested URL was not found on this server.
Apache/2.4.56 (Debian) Server at v**.***.com Port 443
Server installation details are as follows:

KevinTheJedi

ChrisAnders

You’re still running into this “not refreshing” issue most likely because you are not using v1.17.4 (or v1.18) and latest build of the OAuth2 Plugin. You really need to update both and retest.

Now as far as the URL error goes that sounds like you don’t have URL Rewrite installed/enabled in Apache or something got misconfigured in the App Registration or Plugin Config.

Cheers.

jnyunt

Finally I upgraded to 1.17.5 from 1.17.0 after having numerious problem with token expiration. Upgade was simple. Just replace upload folder. After login to system, it said version is 1.17.5. I copied the plugins came with new version to include/plugins folder. When I check the OAuth plugin version, it still says 0.6 sames as last one. Is plugin updated or am I missing someing here?

Thanks

KevinTheJedi

jnyunt

Yes, plugin has been updated since v1.17.

Cheers.

digdilem

We're still occasionally hitting this exact issue with 1.18.0 - I see there's a 1.18.1 but the release notes don't indicate any changes to this side of things.

What I really want to know is - a reliable way to let us know when this has happened. Usually, the first indication is when someone says "Hey, it's been a bit quiet lately..."

This seems to fail silently, apart from when you go into the email settings. The admin webui interface doesn't show any mail failure logs, and the database table ost_syslog just gives lots of cron entries without any indication that the mail fetch failed. (Edit: It is possible the issue is on 365's side when we make a priv change)

Anyone know how I can alert my team when this has happened, so we can go through the re-auth process again?

KevinTheJedi

digdilem

See this thread for alerting:

https://forum.osticket.com/d/104036-notification-when-fetch-stops/9

As far as why it’s still happening you have to make sure you download and install the latest build of the OAuth2 plugin. If you did then you need to restart your webserver and PHP-FPM to clear any file cache. PHAR files especially get cached a lot so be sure to clear any file cache. Also, if using a hosting provider a lot of the times they have aggressive file caching and you can contact them to see how to fully clear PHP file cache on the server.

If it’s expiring every 30 days then you definitely don’t have the latest plugin. If it’s expiring before 30 days then something else is off (either cron, application settings, etc.).

Cheers.

digdilem

KevinTheJedi - many thanks for this! Yep, that's really useful and it works here as expected. I'll wrap that into a script and sleep a little easier.

For reference, it's been fine for several months before failing. I thought I read somewhere else that someone changing privs or roles in o365 can cause a reset, requiring a new Application approval (I hate how complicated MS make authentication in every way). We use least-privilige, so renewing that requires enabling roles temporarily, then three sets of full logins before we can re-auth this app, so it's a bit of faff, but I don't think that's osticket's fault!

Thanks for your help.

jiggs

I can confirm this used to happen to me as well where the token would expire. I was thinking "jeez it's quiet on the helpdesk!" Nope, token was expired. I upgraded to 1.8x and it's not happened since the upgrade. I do go in to emails and check it's not expired here and there just to make sure!

JuanPedroLopez

We had the same issue with 1.17.5 today - had to click submit and re-auth. We are running OAuth2 version 0.6.
I did notify users that we are running the fixed version but seems not?

« Previous Page