Giters

pupilfirst / pupilfirst

A learning management system (LMS) that lets you run an asynchronous online school, where learning is achieved through focused tasks, directed feedback, an iterative workflow, and community interaction.

Home Page:https://www.pupilfirst.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Developer login visibility dependent on ENV['SSO_DOMAIN'] existence

unRARed opened this issue · comments

commented

Maybe more of a Gotcha than a Bug. As a Developer, getting the app running with docker and without using the .env file, I wasn't finding the "Continue as Developer" option from the session form.

Screenshot 2023-11-23 at 11 41 04 PM

The view is checking the presenter for the existence of the SSO_DOMAIN value in addition to the Rails.env.development? check here: https://github.com/pupilfirst/pupilfirst/blob/master/app/views/users/sessions/new.html.erb#L15. The developer-specific option seems like it should be outside of the general oauth scope. It also might be more clear if the default value for SSO_DOMAIN was "localhost:5100" which seems to be the out of the box value currently.

Setting the SSO_DOMAIN value displays all the options, including the developer one:

Screenshot 2023-11-23 at 11 41 24 PM

Desktop (please complete the following information):

commented

So aside from the visibility issue, I was having issues with the oauth action, too, but turns out my port problem was due to my bringing over the bin/dev pattern from Rails 7 (which uses foreman with Procfile.dev).

I just needed to tell the Procfile.dev to use port 3000 explicitly and then it aligned with the seeded data:

Procfile.dev:

vite: bin/vite dev
web: bundle exec puma -p 3000 -C config/puma.rb
commented

This is probably because we're using Omniauth's developer strategy to enable the developer bypass. It should be possible to avoid the check for SSO_DOMAIN just for the developer strategy, though - I'm adding this to our list of bugs.