The whole content of FORMS-file is being sent to all users every time they click on an item in menus or launching a single form

[dariopai]

The whole content of FORMS file is being sent to all users every time they click on any item in the web portal

Every time a user click on any item inside the web-portal the whole raw content of the file FORMS is sent to the browser and without any restriction. So all users, even having non-access to launch any form are able to see the source code of FORM file (groups, categories, source code of all forms, etc is disclosed to all users). Also performance is affected since as FROMS-file-size increased, users have to wait form the download of it every time they click on an item in the webportal.

The code running inside the webrowser is executed from Forms.js:6 as the initiator that calls the URi https://af5-xxxx.local/api/v1/config?timestamp=XXXXXXXX every time a user click on a item either at the menu or launching a form.

To Reproduce
Steps to reproduce the behavior:

1. Open F12 Dev Tools at any browser (Edge, FF, Chrome)
2. Click on 'NETWORK' tab
3. Use AF normally clicking on multiple items
4. Filter out the URLs containing /config?
5. Go to see the RESPONSE body.. and complete "forms" code will be there

Expected behavior
1."forms" raw code should not be visible for all users
2. only minimum code from inside "forms" should be needed to launch a form, at this moment all raw code of all forms is downloaded for a single form
3. config settings as groups, categories, databse queries, etc .. should be hidden
4. the rendering of the webportal is not efficient if all forms-code is downloaded and then proceses at each lick in client-side

Version
ansibleforms v5.0.8beta

Deployment
Deployed ansibleforms with :

• kubernetes
• "forms" are taken from gitlab using multiple form-files

Additional context
Add any other context about the problem here.

Screenshots

[ansibleguy76]

will adapt asap

[ansibleguy76]

this is fixed in new beta. If you could test, would be awesome

[dariopai]

It seems it goes better now! .. I see now that only info related to each form is being downloaded while navigating... although I also see that the source raw code of each form is still there and anybody is able to read it .. I think that the queries to DB "specially" should be obfuscated or blocked in some way but I guess this could be a major change in code.. in the meanwhile I'll continue testing it at my lab and I'll let you know of any other issue. And thanks for your promptly response!

[ansibleguy76]

Yes, it's the client that sends the query request to the backend. I could have a look to have it handled in the backend, but this will require some extra code changes. Not impossible but will cost in speed. The db query would have to be indentified and cached in the backend. The best option I can think of, on top of my head, is setup a redis server as part of the solution. Before sending the form, we identify all queries, replace it with a guid and inject those in the redis. The backend would then quickly be able to grab the guid and use the query stored there. I was always considering a redis to also store the refresh tokens, instead of in the database. I will think about it.

[dariopai]

hi, We have also noticed that as we add more forms to the git repo more time the user has to wait to render a single form (at the launching time). And analyzing the waterfall times from the browser linked to the steps being executed inside the webportal-pod we have concluded that the app is merging and validating "forms.yaml + all files inside /forms folder" every time a form is being launched... could this be the case??? If so, pls consider also (1) merging and validating the forms.yaml only when it changes and/or (2) restricting this validation only to the code behind the form being launched instead the whole list of them.

[ansibleguy76]

that's correct. forms are merged.

[ansibleguy76]

for the last part, forms are indeed merged and then validated. forms can come from anywhere. could be copied manually, can come from GitHub or from the internal editor. i could create an internal heart beat that checks the forms on changes, for example calculate a quick md5 hash. as long as there are no changes, use a cached version. when changed occur, remerge and validate. can you make the separated threads