Hello,
Is it normal that “wrappler dynamic codes” also display when viewing page source code?
Codes like this for example:
<h1 class="display-3" dmx-text="serverconnect1.data.query1[0].SiteTitle"></h1>
<h1 dmx-html="serverconnect1.data.query1[0].SiteEmail"></h1>
Thank you!
Yes, that is normal.
If you want to see the interpreted code, open the page in Firefox -> Right Click -> Select All -> Right Click -> View Selection Source.
Taking one of my documents as an example, the Source Code will show
and the View Selection Source will show as
It is the latter that advanced search engine bots will see.
Hello @Moustapha,
No, there are no security issues seeing the page template.
All the important serverside code is run on the server, so nobody has access to it …
I know you can restrict access to logged-in users, but for pages where no login is required, am I correct in thinking that anyone can access all of the data from a table used in a server action?
In most cases, such tables would not contain secure information. Nevertheless, you might not want users to download all of your data directly. I initially thought Security Restrict can prevent this, but I don’t think it does.
I don’t get your idea Tom?
If you display/render anything publicly on your page, what is the difference if somebody sees it on the page or in a json-formatted file??
@TomD, if it is sensitive info then it should not be included in the query, avoid adding all fields to queries, only add what is needed which you will be displaying so public anyway. Only add queries containing sensitive information when the page is secure.
As I mentioned, in most cases this data won’t contain sensitive data, so typically it won’t matter - but it could.
Eg you can access a massive amount of product data from Amazon - in theory someone could access all of this data, but this probably wouldn’t be feasible without some automated process. You could ask Amazon for a data dump of all of their inventory, but i suspect they would be reluctant to give it to you.
Making data available in this way - eg to potential competitors - is not ideal (but in most cases probably not critical).
Certainly - I absolutely agree.
A huge amount of the big sites today are using JSON data and you can see requests in the console. I don’t think this is an issue as long as you don’t include sensitive data.
So for example my news site or blog site or products site are showing the posts/news/products on publicly accessible pages and everybody sees them. What’s the difference if a crawler/headless browser just copies the rendered data on the page or the data from the JSON?
You can fully use the Security Provider to restrict access to your data feeds for logged in users only
As I said, I don’t think it’s critical. It just makes data accessible in a way which it’s not in a conventional PHP/MySQL setup - in a way which circumvents the user interface.
The difference is ease of accessibility - eg in the Amazon example I gave.
Yes, I realise this - and Security Provider is of course very useful for protecting secure data.
Initially I thought perhaps Security Provided prevented direct access to the data tables in some way (for any user). This was part of the reason for my comments - to confirm that this was not possible (and I can see why it probably isn’t).
But lets say that i want to display specific records to the logged in user (so the page is secured)
what does stop the user from going to code and changing the line from
serverconnect1.data.query1[0].SiteEmail
to
serverconnect1.data.query1[1].SiteEmail
and see other secure users data and change them too.
First, when you filter the query by logged in user ID the query will only return one record as it is filtered like that on the server side… So even if it was possible somehow to change the binding to: serverconnect1.data.query1[1].SiteEmail nothing will be returned.
Second, nothing will happen if you try to change anything like this in the code as it is not quite possible to change it when it is rendered.
i didn’t mean single record queries alone.
lets say we have ticket system and the users are the operators
multiple users have multiple records on the same table. and they are not suppose to see other users records
secondly you can change parameters for the request and resend it to the server… so you can see other data and submit them too.
Then why don’t you filter the database query by user ID? They won’t see anything else than the records related to their own ID.
In your last reply you are not referring to a parameter but to changing some bindings in the code. That is not possible.
This is not a parameter …
Again - filter by user ID and this won’t be possible. It all depends on how you build your queries, and this is not wappler related - it is valid for any kind of dynamic sites.
i never said it wappler specific issue by the way
i have used other systems and the issue is there. all the user have to know is other user id and the parameter name.
That is absolutely wrong. This is all wrongly designed system, you should not rely on some GET parameters to filter sensitive data!
If you filter the query by the logged user ID i.e. get the logged user id in server connect steps, and then filter the query in the server connect steps using it, nobody will be able to access anything else by changing any parameter …
