strange auth issue in some browsers.

[eriko]

This will sounds nuts but here goes. We are starting to test UDOIT with faculty and some are getting authentication or configuration errors when then access it. I am also getting authentication errors. Here is the really weird part. The two testing faculty get the errors while using firefox but not chrome or chrome and IE (linux user and window user) I get the error when using chrome on a mac in my default 'person' but if I create a new 'person' that one works.

From watching the login I have noticed that, for me, while using chrome the custom_canvas_api_domain was not picked up and this would cause auth or configuration issues. I have deactivated all extensions and restarted chome and the issue persists. I am also running the current version on heroku.

I am wondering if there are is a know issues with some sort of browser security settings?

[bagofarms]

These issues sound similar to ones Simon Fraser University was encountering. They were encountering different results with different browsers and users, and they ultimately discovered that it was an issue with the SSL certificate for the server that was running UDOIT. In their case, I believe it was self-signed, and different web browsers react differently to self-signed certificates. Additionally, we've noticed that Canvas itself will exhibit some odd behavior when trying to load an LTI that doesn't have a proper SSL cert.

Hopefully that gives you something to go on. Let me know if that helped.

[eriko]

Could it be that the cert heroku is using that causes this?

[bagofarms]

We have multiple developers using Heroku connected to our production instance of Canvas, and we haven't encountered this issue before. Could you send me the exact error messages you are encountering?

[eriko]

In my case with chrome it is " Authentication problem: Please contact support." from oauth2response.php in debugging it seems like base_url is not getting saved in the session from when the request authentication page gets loaded. It also seems like no users where being stored in the database until I switch browser profiles or use other browsers.

[eriko]

In the case of the IE and FIrefox users they are getting 'Configuration problem, please ensure that your instance of UDOIT is configured correctly.'

[cooperfellows]

That error appears in only one place in the code base.

Which indicates an issue authenticating that is probably related to the consumer key or shared secret:

// Initialize, all secrets are 'secret', do not set session, and do not redirect $context = new BLTI($consumer_key, $shared_secret, false, false);

Can you confirm those settings are correct, and also take a look at your error logs, as there should be some good information in there?

[eriko]

Yep the settings are fine. As I said UDOIT works in some browsers and profiles and not others. When I was chasing this down it seemed like something was stopping session storage of the settings for some set of browsers/profiles but not when the use other browsers and computers. The paranoid part of me is wondering about some sort of sublet system compromise on our end.

[cooperfellows]

Nothing in the logs for those specific browser/ussr combinations?

On Mon, Aug 22, 2016, 5:07 PM Erik Ordway notifications@github.com wrote:

Yep the settings are fine. As I said UDOIT works in some browsers and profiles and not others. When I was chasing this down it seemed like something was stopping session storage of the settings for some set of browsers/profiles but not when the use other browsers and computers. The paranoid part of me is wondering about some sort of sublet system compromise on our end.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/ucfopen/UDOIT/issues/189#issuecomment-241550605, or mute the thread https://github.com/notifications/unsubscribe-auth/AGe8zQiXJPpzOseHx7UOQTlM3QODJRK8ks5qig9zgaJpZM4Jn2nf .

[eriko]

Nothing exciting. I did add some debug code (since removed) the showed that for me in chrome 'custom_canvas_api_domain' was not getting converted into base_url and stored.

[bagofarms]

Ok, here's my take on the whole process: If $_POST['custom_canvas_api_domain'] was not set, you would get the "No Domain Provided" error page. If that value is set, then it will get saved to $_SESSION['base_url']. If it didn't get saved to the session (for various reasons), then you would receive the "no domain provided" error after the oauth2 process completes and the app returns to index.php. If it does get set, then $base_url should also get set to the same value.

So if you haven't encountered an error page by then, $base_url and $_SESSION['base_url'] should both be good. The condition i'm referring to starts on line 58 of index.php (https://github.com/ucfopen/UDOIT/blob/master/public/index.php#L58)

[eriko]

The missing base_url is in the case of " Authentication problem: Please contact support." from oauth2response.php In this case, even though the tables are using the updated sql, nothing seems to get stored.

In the case of "'Configuration problem, please ensure that your instance of UDOIT is configured correctly.'" I have seen the screen shots but can not replicate it with an instance of the app with debugging coded added.

[bagofarms]

Are you getting any errors back from the database? Is it even getting to this line: https://github.com/ucfopen/UDOIT/blob/master/public/oauth2response.php#L90 ?

[eriko]

I makes it to https://github.com/ucfopen/UDOIT/blob/master/public/oauth2response.php#L71 At that point the both the $_SESSION and base_url are empty

Both of the following return nothing when called right before L71 error_log($base_url); error_log(implode($_SESSION));

[bagofarms]

Are you still experiencing this issue?

[eriko]

We did get it a couple days ago after updating to current a couple days before.

[bagofarms]

The auth process is going to change completely in UDOIT 3.0.0. I'm closing this request since it won't be fixed in UDOIT 2