I noticed on the directions for creating a public login page, there is a singleton class that we create to contain the login function. It indicates shared singleton class, but should it be a session singleton class? Thanks.
Hi @musseman ,
I guess you refer to this fonction: Creating a login page for public access | Qodly Developer Center
Well it does not have to be a session singleton. It would still work though.
The session command always refer to the curent user session.
Putting this singleton as shared, and not session shared, ensures this object is unique overall the app.
Declaring this singleton as session singleton would be interesting if it had had at least a property that you would want to be session specific. Which is not the case here. The sole use of this singleton, as is, is to check user and password and set session privileges.
Im not sure about scoping so just want to double check :but if I have 3 people logging in- Each of them, when logged in might not have the same role/privilieges. So what happens when one user with limited privleges logs in and then right after, another user with full access privilege logs in? If I want the app to remember one user goes by Tom, and the other goes by Fred?
Hi again 
Privileges are store in each user’s session.
The shared singleton is indeed unique to your app, but it is called with the session context. So the session object where it puts privileges is distinct for each user.
If you want your app to distinct user names, provided you list your users in a table, well you can deal with it in various ways.
- Store user name and or email directly in the session upon loging in (just after privileges), and code a fonction returning that as an object Qodly Source
- Or have a singleton or function returning the userEntity, mapped to a Qodly Source of the same type, based on session email
What is important to understand is that the Session command returns always the session of the user, which is different from the session of any other user.
I think I get it. Trying to understand reason for singleton in this case. Could we just simply add the login function to the datastore and avoid use of singleton completely? Is it just a preference? pros/cons etc?
Yes you could also put the login fonction in the datastore. It would work the same. In a way ds can be viewed as a kind of singleton (although you cannot add your own properties).
I prefer using a singleton to group this kind of function in a logical set. You’ll quickly realize you’ll need other functions related to login, and it is not a bad thing to put them all in one place.
It may also help when it comes to set permissions.
But it is a matter of preference.