I’d like to log into my perspective session via custom made page. so far the login works, but it won’t authenticate against ignition. So, when I try to open a view with “View Permissions” it won’t give acess.
I try pushing the user data into the session auth data part. Mayby that’s not meant to be?
so the setup is:
dropdown for a assembly line
user dropdown for every user that is allowed for this line (by user role/no need to type)
login button with onClick event script:
success = system.security.validateUser(username, password, "default")
if success:
logger.info("Successful user login detected: %s."%(username))
self.getSibling("Label LoginFailed").props.text= ""
#set user auth in session props (with user object)
user = system.user.getUser("default", username)
self.session.props.auth.authenticated = True
self.session.props.auth.user.id = str(user.id)
self.session.props.auth.user.userName = username
self.session.props.auth.user.firstName = user.get(user.FirstName)
self.session.props.auth.user.lastName = user.get(user.LastName)
if user.getContactInfo().isEmpty() == False:
email = user.getContactInfo()[0]
self.session.props.auth.user.email = str(email).split(":")[1]
self.session.props.auth.user.roles = user.roles
# load view
system.perspective.navigate(page="lineStopOverview")
system.perspective.openDock("TopDock") #"Docked Windows/North Dock Navigation")
else:
self.getSibling("Label LoginFailed").props.text= "Login failed"
Pretty sure all of those auth fields are strictly read-only, otherwise what’s the point in having security of all someone needs to do to login is to overwrite some fields. What we need is a login scripting function which is missing.
I figured at was the case. So this means we can’t provide our own login buttons. Will you guys add auto login on launch at some stage? Or should we adopt a new philosophy of using the non auth state for that?
There does exist a system.perspective.login scripting function. Invoking it will redirect the browser to the IdP's login page, where the user may enter their credentials (if required), and upon completion, the IdP will redirect the user back to the Perspective page they were on before the login was triggered.
Correct me if I am wrong, but looking at the original post and some of the replies in this thread, it seems like there is a desire to bypass the IdP system altogether and build and embed a custom login page within Perspective itself using the user source profile system. While it's possible to build the pages and views in Perspective and to trigger scripting functions to validate the credentials against a user source, Perspective's security model is built upon Identity Providers and Security Levels, and so it is not possible to coerce a Perspective session into setting the authenticated user and security levels yourself (they may only be set by the system when it processes a valid IdP response and sends it through the relevant attribute mappers, user grants, and security level rules defined on the IdP). As mentioned above, the session.props.auth.* session props are essentially "read-only" and managed by the system itself.
Could you clarify what you mean by this? Are you looking for a Perspective-analogue to the Auto Login feature in Vision (designer project properties settings shown below)?
If that's the case, the pattern in Perspective is to disable the Authentication requirement at the Project level, which is accomplished by not strictly requiring a security level in the Authenticated tree in Designer > Project Properties > Perspective > Permissions. This will allow the user to startup the project without logging in, which is effectively the same as "auto-login" using hard-coded credentials, except the user doesn't take on the username of the hard-coded user, but is instead treated as anonymous or unauthenticated. Then, if you want to protect certain script actions or views with authentication, you can set their respective security level permissions in their designer configurations.
If you are looking for something else, please elaborate, we'd like to better understand what that is. There may even already be an idea in the ideas portal submitted for it.
Correct, this is what I was referring to. What you said RE not requiring login makes sense, it's just a bit of a mentality shift. Really, there's no point in having a particular user automatically logged in to enable access to certain areas or functions as it defeats the purpose of having a user login. I don't really know why I would set it up like that originally to be honest; old habits die hard..
