I know there are different avenues to get the Logged In User’s Identity and bind such things as their full name, city, etc that may be displayed on the pages they use while logged in,
or to restrict views to their own data, filtering out other users.
I can already do this – but – I decided now to review this page –
And I notice there were 4 Security Components then & now 5 Security Components in 2022.
But here is how adding Security Restrict to Security Provider looks like these days.
I already set up a Security Provider days ago. It is in use now to protect the user form page after a User attempts to successfully or unsuccessfully log in.
This Security Restrict setup asks for Properties that I already completed when I created the Security Provider “security stories”.
Rather than plow on trying to guess the underlying programming changes in Wappler I am stopping here to ask these questions.
-
What does Security Restrict do that is a separate function and useful for getting and binding User details to pages?
-
If I want to keep going with using Security Restrict on top of Security Provider do I fill in these properties AGAIN that already exist as properties of Security Provider?
-
What, please, are my next steps to creating what the original Documents instruction promised : Getting User’s details & binding them to a page? I can already get them from the table I use to match login credentials with a table of authorized users
Last updated: