Hi Alexandre,

Setting the appropriate permission areas for your screen is the way to go. If a user doesn't have the appropriate permission areas the platform will throw a security exception when the screen is reached (through direct typing or any other method). You can later handle this exception at the web flow level to redirect the user to another screen (such as the login screen or a custom "no permission" screen) or take any other action that seems fit to you.

You can see an example fo how this is done in the OutSystems Style Guide template eSpace and check https://www.outsystems.com/help/servicestudio/4.2/handling_security/about_permission_areas.htm for more on permission areas and how you can use them to protect your screens.

Hope this helps, cheers.

Hi João.

Thanks for your answer. In fact I did not make my self clear. You'r right about the permissions.
In fact what I need is a way to protect form direct typing a url because the pages must be used without logging in (ubnregistered users). Tat means that I can't use permissions. I want to ensure the users start in the first page and go all the way to the last, without breaking the chain. Only after they complete the process I can create the credentials for them in the system.

Thank you.

Hi Alexandre

 

Have you considered a session variable that holds the current step/page where that user must be, and check the session value on the preparation of each page?

 

If users that should be on the firsst page try to access the last page, they are redirected to the first page again.

 

Hope this helps you identifing a solution to your problem.

 

Cheers

 

Miguel João

Miguel João's suggestion is of course a valid one but the way I would go is to create an encrypted token that is passed as an input parameter from screen to screen. The steps should be something like

• Create a unique token per user and per page - This means it should be something like: token = UserId (or UsermasterId) * 100 + step number.
• Encrypt the token - I suggest you concatenate your token with a password of your choice: something like EncryptedToken = Encrypt(token + "your password") where encrypt is the platform's built-in function
• Validate the token in each screen preparation - In each screen preparation you re-calculate the expected encrypted token: ExpectedEncryptedToken = Encrypt((UserId * 100 + screen step number) + password) and check if the encrypted token provided as an input parameter is the same as the expected token.
• Proceed or send the user back to step 1 (or to an error screen) according to the output of the validation function

Note: You can set your password as a site property so that you can change it from time to time
Hope this helps, cheers.

Hi João.

Thanks for your reply.

I will try something like what you explained. The only diference is that the users are not authenticated, so they don't have UserId. The pages will accessed by anonymous users, like I explained.

You said that I can place the passord in a site property, but isn't that dangerous? Can anyone access it in this case?

Thank you.

Hi Alexandre

 

Anyone with read-only access to the eSpace in Service Center, or anyone with database access, will be able to see that password, if you save it as a site property - but I guess that will not be a problem with your (anonymous) end-users?

Hi Alexandre,

You're right about the UserId... my bad.

Regarding security: Acácio pretty much summed it up. It depends on your level of trust in the other applications on your server. In my opinion the ability to change it easily and frequently compensates the additional "exposure" but, as always, it depends on how critical and confidential is the information you're protecting.

Some additional tips to compensate for the UserId... errrrr... let's call it a misunderstanding :)

1. If you have Enterprise Manager published on your server you should have an extension called Random which as a handy action called NewGuid which generates an unique GUID (Using the System.Guid .NET structure, I think)

2. You can easily store this GUID in a session variable or a cookie if you want it to persist between browser sessions. To read/write a cookie you can use the appropriate actions on the HttpRequestHandler extension, also available when you a have enterprise manager published on your server.

If you have any question regarding how the GUID or the cookies works, let me know and I'll try to help you.

Cheers.

Hi João.

Thank you for your reply.

No problem. I will give a try on the method you'r describing.

Thank you.

I was searching for for a solution of this kind and I found this thread exactly one year old. Anyway, I found a solution which I believe that is simpler then the ones described above.

Although the users are "anonymous", you can create an user called "user" and in the preparation of the first screen, you login the user through the built-in action "Login". You just set all the other pages as restricted to "anonymous" users and add an exception handler for "NotRegistred" and point it to the first page.

The behaviour will be the one desired. If someone tries to reach any page without calling the first page, they will be redirected to it because they are not logged in. This way I was able to have that behaviour without much effort.