Update code to label users with guest/ member in the same manner as the lab07_starter code.

[qiandrew]

EDITED P. Conrad, Thu March 4, 4pm

The STARTER_lab07 code has levels of login for guest, member, and admin based on whether the user's login is in the "hosted domain" defined in application.properties.

Implement that, and then be sure that all features in the application that can update data are restricted to only tutors, instructors and/or admins. But go ahead and ALLOW logins for anyone with a valid Google email address.

New Acceptance Criteria

• [x] If I login with a non-ucsb email , I see "guest" in the navbar, and I have no menu items that allow me to access any pages where I can modify or enter data.

• [x] If I login with a ucsb email, I see "member" in the navbar, but I STILL have no menu items that allow me to access any pages where I can modify or enter data UNLESS my email is in one of the tutor, courseOffering or admin tables.

• [x] If I login with an email in the admin table, I see "admin" in the menu bar.

As a separate issue, we might add validation so that the emails in the admin, courseOffering and tutor table have to be @ucsb.edu emails---but that's not part of this issue.

Background

This issue was originally:

Restrict logins to only @ucsb.edu and/or restrict logins to only users that have an email in the tutor and/or admin table.

However, I don't think we understand how to do that properly within the Spring Boot security framework at this time. The approach that was taken in this issue doesn't seem sound from a Spring Boot Security architecture standpoint.

I have replaced this with an much easier issue to implement--and I'd encourage the team to start on a new branch.

You may be disappointed in this--but this is a constant feature of real world code development. You don't merge code just because you worked hard on it. You usually end up throwing away at least half to 2/3 of the code you write. That's a normal part of the process.

[qiandrew]

Acceptance Criteria: Login as a non-ucsb member and fail, tests to accompany, or manual test.

[larkJennice]

Acceptance Criteria: 1. Instead of letting email not on the list become guest accounts, we can set an exception to avoid guest emails to login to the main page.

2. The dividebyzero exception in lab04 about calculating is a good example. Our page doesn't need to pop-up new page instead just simply tells this restriction once the user inputs a email that is not on tutor and/or admin table.

[zacharyfriedland]

Possible documentation: https://stackoverflow.com/questions/37264739/how-to-restrict-to-a-specific-domain-to-login-with-spring-boot-and-oauth2

[XhenryZhang]

User Story: As a lab tutor at UCSB, I can use OpenLab without worrying about people from other domains accessing the website. The course/lab/tutor information will only be accessible to those in the UCSB domain, which helps with student/tutor privacy.

[pconrad]

New User Story:

As a user of the website, I can access functions that modify data if and only if I am logged in and

• my google email is in the admin table
• my google email is in the courseOffering table
• my google email is in the tutors table

And I can only access the appropriate functions for my role.

However, I can still "login" to the application

REASON: we need more infrastructure in the application to do Spring Security role based login restriction properly, and there isn't time to do that before Sunday 5pm.

@qiandrew @XhenryZhang @zacharyfriedland @larkJennice