OAuth SCP login redirecting to Client page: Page 2

OAuth SCP login redirecting to Client page

JuVDC

KevinTheJedi
Hey Kev, I am on 1.17.1. Will try with 1.17.2. You think this will solve it?

KevinTheJedi

JuVDC

I'm unable to replicate this so I'm almost sure it will.

Cheers.

FIASJason

JuVDC Please provide an update once you've updated. I would be very interested in the results.

MarkMansveld

We've updated to 1.17.2 but it hasn't solved our problem.
Fun thing is that we have a test environment, that uses the same O365 app registration and there it works, but in our production machine it does not work. Config is the same.

ramrajone

Have you given the user consent?

MarkMansveld

Yes we have. As I said. Both our test and PRD environment use the same app registration.

And in test it works, just not for PRD.

ramrajone

MarkMansveld
Check your Azure signing log
I tested it works, and the reason it was failing was due to the secret, when you make changes, you need to re-enter the secret, even though it was not giving any error

MarkMansveld

Checked the logs. They report success. And indeed we do not get a failure with loggin in. Just redirected to the wrong place.

ramrajone

MarkMansveld
Maybe some files did not copy over when you upgraded?
You can try deleting plugin and re-added
Check your server logs, something must be off, maybe rewrite mod?

This is only permission needed: I have tested on Test server and Live

FIASJason

MarkMansveld Same here.

At this point, I've gone back to LDAP authentication and using our own SMTP relay to send helpdesk responses. The only downside is that we can't have tickets by email anymore (because the Oauth doesn't work). But at least we can use the helpdesk.

Ideally, I'd like to get Oauth up and running - then users won't need to sign in, we can implement tickets by email again, and I can open the helpdesk to other organisations.

FIASJason

ramrajone I've reinstalled the plugins, and tried different versions of PHP, checked the logs, etc. Can't find anything. It's entirely possible that I've missed something, but I'm at a loss.

The redirects are working OK, at least in terms of standard login. I certainly haven't made any manual changes to the redirect rules, so the Oauth redirect rules should be standard.

ramrajone

FIASJason
Something must be missed, double-check the official documentation https://docs.osticket.com/en/latest/Guides/OAuth2%20Guide.html

You can check my post, which is created for my own reference, maybe it gives you a pointer https://howtohelpdesk.com/how-to-setup-oauth-on-osticket-using-microsoft-365

FIASJason

ramrajone I've gone through the documentation and set up Oauth at least 4 times, following the instructions exactly.
As it happens, your post was one of the top results I found on Google when researching this topic. I set up a separate App registration for the mailbox Oauth using your guide - again, multiple times.

Still no go.

I'm beginning to think that our firewall is doing something stupid, but our firewall logs don't show anything being blocked, and we use Oauth/SSO for many other applications without issue. Given that most others don't seem to have an issue, I'm starting to think that it's not an osTicket issue. I remain open to all possibilities, though.

KevinTheJedi

FIASJason

Do you possibly have any security rules on the webserver that could be blocking or preventing the redirect?

Have you tried completely deleting the OAuth2 plugin, deleting anything associated with it in the database (maybe records from previous attempts that weren’t deleted), and re-installing it, etc.?

Have you checked your IIS logs to see if the url rewriting is not happening?

Cheers.

ramrajone

FIASJason
If you like to test this, create a new folder within the same server where your current osTicket is installed, for example:
let's say your current install is on: /www/osTicket Then create a folder in it called Test /www/osTicket/Test
Then download a fresh copy of the new osTicket from osticket.com/download version 1.17.2 Go through a setup like it's a new install with a new database and install the Oauth plugin and see if that works for you.
You can create new app registration for this Test to keep it live server and Test separate

FIASJason

KevinTheJedi As far as I know, I don't have any rules that would block/prevent the redirect - it's a bog-standard IIS server on a VM built expressly for osTicket.
I have deleted and re-downloaded the Oauth plugin.
I'm not sure what records would need to be deleted in the database?
I posted a snippet of our IIS logs in my original post, which shows 302 redirects occurring.

KevinTheJedi

FIASJason

Have you upgraded to v1.17.2 yet? Also, after upgrading apply this change:

https://github.com/osTicket/osTicket/pull/6379

Cheers.

FIASJason

KevinTheJedi No, I haven't upgraded yet. Given that we have a helpdesk that works for the most part, I'm reluctant to make any changes to it at this time. Especially since others in this thread are having the same issues.

We'll have time to work on this again in a few weeks. In the meantime, I'm hoping that others with this issue will post their experience with your advice.
Thanks for taking the time to troubleshoot.

KevinTheJedi

FIASJason

Well I can say that with the hosted platform there are no more issues with OAuth2 SSO since the upgrade and the patch I referenced. But I understand.

Cheers.

FIASJason

ramrajone Excellent idea, and I can't believe I didn't think of it before. I'll take a look at this issue again in a few weeks.

FIASJason

ramrajone
I'm a bit late replying, but I've finally had time to set up a test instance in a subfolder as you described, and I'm getting a URL Rewrite Module error:

I'll try installing a test version on another machine.

« Previous Page Next Page »