14
Views
3
Comments
[BDDFramework Client Side] Securing BDD tests by IP address (or other methods)
bddframeworkclientside
Mobile icon
Forge asset by OutSystems
Application Type
Reactive

I am working on a little project to automate the BDD (client side) tests we are generating for a project. My current idea is to create a little app that tracks tests and executes according to various settings controlled by the user.  This would look a lot like a CI/CD pipeline, which we do not have at the moment - in order to get there, I need to demonstrate the value of having the test suite in the first place.

Anyway, one holdup on full BDD implementation is the requirement that the test pages have Anonymous access enabled.  Our development environment is not secured behind a VPN and for various reasons that is not an available path at the moment. Security does not like the idea of exposing all our test scenarios on a public page, so I'm brainstorming ways around this issue.  I'm thinking of wrapping the test pages in an IP check (assuming the Test Runner API calls come from a fixed IP).

Has anyone been down this path before?  Am I missing a more obvious solution?  

Also, I would love to hear from anyone who has built a custom test management/execution tool - I'm a big fan of the BDD approach but I've always been thwarted by the lack of tools to actually manage a robust test suite. 

2025-12-15 09-29-24
Thibaut G

Hi Douglas,

Is this still relevant?

How do you plan to securely wrap the test pages in an IP check? Additionally, why does the page need to have anonymous access enabled?
 I'm very interested in your approach.

Kind regards

Thibaut



2023-05-16 15-02-15
Douglas Aldridge

The page needs anonymous access because the API Test Runner (used for automated test execution) loads the page via a headless chrome browser, which cannot log in.  In fact, our tests that execute a login (to test specific role security) fail because the login does not persist.

I wasn't able to get the IP address check working, at the moment the workaround I'm using is to check the user agent:  Index(GetUserAgent(),"HeadlessChrome",True) > -1 and throw the NotRegistered exception only if that is false.

I've been looking into this for a while and unfortunately it seems that OutSystems is not suitable for automated testing in a CI/CD pipeline.

2025-12-15 09-29-24
Thibaut G

I was interested because i was hoping  to improve my current approach to restrict access to specific reactive web pages.
Currently, i use the forge component ClientIpVerifier in the data action that runs "At Start" of that specific webpage.
https://www.outsystems.com/forge/component-overview/10983/clientipverifier-o11
 Is this not a feasable aproach for your case?

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.