Modifying the plug-in allowed us to get connected, so thank you for that!
Our support staff didn't notice that we weren't getting tickets until today, so we ended up with eight days of tickets in their queue once it started working again. How they didn't notice I have no idea, since now they've got 40 tickets to clear (or maybe they did and were enjoying the vacation from tickets). Is there a way to get some kind of notification from osTicket when the token expires?
Not at this moment but something we’ve been toying with. So maybe it will be implemented in the future; I can’t say for sure.
Cheers.
KevinTheJedi I downloaded the oauth2.php file from github and modified that instead of what had come from extracting the plugin on our instance, made the changes, uploaded it, and everything is working great! Thank you for all your help!!
idunbar_usf For what it's worth, we frequently run into the issue of the token expiring without us noticing. The token doesn't seem to be persisting beyond 30 days for us. I've gone through the documentation and steps a number of times and everything looks correct, but as I'm learning through this process, something seems to be a bit different with our installation. Not sure what though.
Anyway, we have a script that sends a test email to our system each week, and when we see that the ticket wasn't opened, we know we need to manually refresh the token. It means that there's a window of time where new tickets possibly aren't being submitted, but for our environment, a couple of days isn't a big deal.
What version of PHP are you running? Are you certain you have the latest build of the plugin installed? We did have that issue long ago with Microsoft emails but was fixed a while ago.
Cheers.
njohnson We did have that issue in the past as well. It has not been a problem for us in the last year or so, I believe.
KevinTheJedi Thank you for the answer. It would be very helpful in future.
KevinTheJedi This worked for me.
This authenticated for me, but isn't actually pulling any emails through :-(
Edit2: This actually DOES work for me. I had no emails coming through for about an hour (on this mailbox, other mailboxes continued to work) and then as if by magic they started flowing through!
KevinTheJedi
PHP 8.1.30
osTicket 1.18.1
Oauth Plugin 0.6
TBH, I don't know for sure if we're running the latest build. I had updated it after the Token-timeout issue was supposed to have been resolved, but we never noticed a difference. I'm probably blind for not seeing the plugin version be referenced anywhere...what's the current version?
Would it break anything if I deleted the plugin from our installation and installed the current one that's posted (recognizing I'd need to do this code fix again)?
0.6 is latest but we don’t update the versions on the plugins as often because it’s usually very minor changes. So you really have to go off of when you downloaded it.
Don’t delete from UI just delete the existing PHAR and replace it with the latest build.
Cheers.
KevinTheJedi Thanks! I've replaced it as of today, so hopefully all our osticket problems are now resolved! You've been a great help!
PHP 8.0.27
MySQL 8.0.15
osTicket 1.17.5
Oauth Plugin 0.6
Windows Server 2022
I've been using OAuth2 and just ran into this issue. I've followed the steps to unpack the auth-oauth2.phar file and edit the database. Everything there matches what @KevinTheJedi wrote here (https://forum.osticket.com/d/105728-ms-oauth2-error-the-api-version-v2-has-been-depreciated/41). OAuth2 authorization is successful, but I'm getting the 5.7.3 Authentication unsuccessful on the outgoing (SMTP).
In addition, these are full mailboxes, not shared. Authenticated SMTP (and all other protocols) is enabled on the user's mailboxes.
Check if the API Permission is added and admin consented in the app registration. Make sure the user has Authenticated SMTP enabled in O365. Also make sure the user doesn’t have a policy attached that restricts/blocks SMTP.
Cheers.
KevinTheJedi
Thanks for the reply. I've verified the API permissions and Authenticated SMTP. No policies in effect that would restrict/block SMTP.
KevinTheJedi These are real/full user mailboxes.
KevinTheJedi
Yes, I am. The enterprise app and app registration is shared among all of the email accounts within osticket, but I am using an incognito window and authenticating with each unique user/mailbox login. Also, if it matters, I’m using the tenant-created accounts with onmicrosoft.com logins/addresses. It’s been setup that way since changing over to OAuth.
Then you should be fine. Maybe disable SMTP, reenable it, and retest for each account?
Cheers.
We also have this problem with SMTP.
The "hack" worked OK for the accounts we use to only receive email, but the account we use to send cannot authenticate:
This is not a new account, used to work fine up until yesterday.
