In order to protect the data in the firebase data store per application, we need to have some form of authentication so we know who the user is and authorization based on their role.
@kriskelly and I agree that the route to a new instance of this resource should always be returned. https://www.firebase.com/docs/web/guide/login/custom.html provides more information. It is possible to pass extra information in the JWT such as a role.
By default, the role returned could be 'guest' or 'anonymous', but could also be 'student', 'teacher', 'admin' whatever we wanted.
This ties into the OAuth plan somewhat. If the user makes a valid OAuth request for a Firebase web token, then the LMS can assign the appropriate role in the JWT.
In order to protect the data in the firebase data store per application, we need to have some form of authentication so we know who the user is and authorization based on their role.
In the LMS, we need to implement a resource that delivers custom firebase tokens. https://www.firebase.com/docs/security/guide/user-security.html#section-custom.
@kriskelly and I agree that the route to a new instance of this resource should always be returned. https://www.firebase.com/docs/web/guide/login/custom.html provides more information. It is possible to pass extra information in the JWT such as a role.
By default, the role returned could be 'guest' or 'anonymous', but could also be 'student', 'teacher', 'admin' whatever we wanted.
This ties into the OAuth plan somewhat. If the user makes a valid OAuth request for a Firebase web token, then the LMS can assign the appropriate role in the JWT.
cc/ @petergault