## WeBWorK Main Forum

### Safari issue with LTI in 2.16

by Larry Riddle -
Number of replies: 3

One of our instructors created an assignment in Canvas that uses WeBWorK as an external tool. The assignment opens WeBWorK directly in Canvas. When one of his students tried to do the assignment using the Safari browser and clicked on the assignment link, she was authenticated in WeBWorK and the WeBWorK homework set page appeared in Canvas. But when she clicked on one of the problems in the homework set, she was kicked to the WeBWorK login page rather than being shown the actual problem.

The other option in Canvas when setting up an external tool is to have it open in a new browser tab. If this option is checked, Safari will NOT take the student to the login screen, but will display the problem that was clicked as expected.

I don't know if this is a Canvas issue with Safari or a WeBWorK issue with the combination of Canvas and Safari. With Firefox, WeBWorK correctly displays the problem under both options in Canvas -- display in Canvas or open in a new tab.

Any thoughts about what might be making WeBWorK go to the login screen as described above when using Safari rather than display the problem page?

### Re: Safari issue with LTI in 2.16

by Danny Glin -
Recent versions of Safari block all third-party cookies by default. I suspect that this is what is causing the issue. As an experiment, you could have a student unclick "Prevent cross-site tracking" in Safari preferences, and see if this fixes the issue.

In the future more browsers will be going this route (Chrome has plans to do it at some point), so this will become a bigger issue. I don't know enough about the cookie settings in WeBWorK to know if there is a way to prevent this by tweaking the WW settings, but it is something that will need to be addressed.

### Re: Safari issue with LTI in 2.16

by Larry Riddle -
Upon further testing, I discovered that changing $session_management_via = "session_cookie"; to$session_management_via = "key"; fixes the problem with Safari.

The defaults.config file in 2.16 says "session management using cookies is more appropriate when external authentication systems are used, e.g., LDAP, LTIBasic, etc.", and session cookie now seems to be the default in 2.16, but this is what may be causing the issue with Safari. I don't know all of the ramifications, however, of using "key" rather than "session_cookie" for the session management.