Hi everyone,
I’d like to get your opinions on the best approach for validating client IP addresses in OutSystems. Here’s the situation I’m facing:
I believe that validating the client’s IP address in the On Initialize event of each screen ensures that the user’s access is validated right from the start, preventing unauthorized access before any data is loaded. This seems like the most secure approach, as it blocks unauthorized users immediately, right when they try to access the page.
However, I’m aware that if IP validation is handled within a Data Action, there is a risk that users outside the allowed IP range could still access the screen since the Data Action is executed after the screen has been loaded. This could potentially cause security vulnerabilities.
The issue I’m encountering is that validating the IP address in the On Initialize event often triggers warnings from OutSystems about performance impacts. This raises concerns about potential slowdowns when the screen loads.
What do you think is the best solution here? Should we prioritize security by validating IP addresses in On Initialize and deal with performance optimization separately, or should we find a way to handle it within Data Actions without compromising on security?
Looking forward to hearing your thoughts and suggestions!
Thanks!
For me, i'm checking whether the logged-in user is allowed to access the screen. So what i did is that, i have a data action just to check whether able to access. Then I have an OnAfterFetch to either direct them to Invalid permission screen, or to refresh the rest of my data actions/aggregates of the screen. Of course, do have to remember to set all rest of the aggregates/data action to Fetch On Demand.
This way, thou the user might still be able to see the widgets, layouts etc on your screen, but i think i would think the actual data have not been fetched.
Hi @Jun Mun Chan ,
this has an undesirable effect on performance of initial load, the refreshes in your OnAfterFetch will now all run one after the other, instead of in parallel.
If you want to limit the screen to only users who have access, why not just use the checkbox at screen level on user roles ? That check box will protect all your aggregates and data actions of that screen.
Dorine
Hi @Dorine Boudry ,
You are right, the aggregates will not run in parallel anymore.
What happen was that, we were (this happens in my previous company) checking whether the user is from a particular department, and maybe only certain departments can view. Further to that, each user has a position (example temp, perm, contract, student-full time, student-part time, staff-teacher, staff-professor etc). So it was really quite hard for us to manage the roles.
So end up what we did, is in our first data action, we will join the aggregates (staff, student, department etc), from there we still have to do some filtering to assign whether they are admin, email-admin, staff from certain departments can see this-while staff from other departments can see that etc
Only when valid, then we will start to refresh the other aggregates. Furthermore, the conditions for the aggregates, are very dependent on this data action, and there are more filtering to be done as well
Thou for this particular use case, i did take a quick look at the mentioned forge component. In their aggregate filter, they do have a IsValidIPAddress.
So maybe the screen can have a local variable, the first data action will assign the result to this variable. Then depending on this variable, the rest of the aggregates will load/don't load. Sounds doable to me, thou have not try it out yet.
Thank you.
the method i suggested, does not work.
It is possible to have the aggregates and data actions that actually retrieve the data, use as part of their filter, results from the first aggregate that checks permissions.
OutSystems platform is smart enough to only start the dependent aggregates after the first aggregate is done. So all can still be "At Start" and they will all run in parallel after the first one finishes.
So no need for On Demand, no need for an OnAfterFetch, no need for local variables