I am looking into centralize encrypting Site_Properties so password or keys etc. are not shown in plain text in ServiceCenter. I have most worked out however I seem to missing an important piece.

As far as I understand the System.Site_Property_Definition contains your, well, definition of the property with the default value. I assumed the System.Site_Property table contains the actual value if you fill it in in servicecenter. However when I set an actual value I can't seem find it anywhere in the database. There is no new record in System.Site_Property added, however ServiceCenter reflects the new value, so it must be saved somewhere.

Any ideas on what I could be missing? Or I have this completely wrong?


Kind Regards,

Hello Dirk,

What are you using Site Properties for?

As you know, they are cross section variables, meaning that all users see the same value.
And if you change in logic its value, you invalidate the cache of the application.

The main use of site properties is for application configuration.


Unless this is the effect you're looking...
I would opt to save the info directly into database in a normal entity. 


Hi Eduardo,

Thank you for your reply!

Let me explain a bit better what we try to accomplish.

We have a number of sensitive properties that change per environment, such as the password of a certain service account. They are now stored in Site Properties so they can be set when we deploy an application through our environments. 

So we would only set them ones for each environment, but in an encrypted state. We don't want passwords just be visible in an interface, even if we can limit certain people to those servicecenter pages.

We also want a system that we can re-use through our different applications, so although a shared module (that has a database to store the values and an interface to encrypt them) that we reference in all applications is an option, I thought site properties would be the best fit.

There is also this post that explains it: https://www.outsystems.com/forums/discussion/26811/how-to-use-cryptoapi-to-encrypt-my-site-properties/

Hope this makes sense/



Hello Dirk,

Yes, it makes sense. :)
Site properties have two advantages:

1. You can change them from Service Center.
2. You don't need any extra logic to deal with database, as it works out of the box.

You can still have an application that can be used by other applications.
While Site Properties can't be shared you create a public Server Action wrapper to recover its value.

And to store the key, you can use the approach mentioned by Ricardo Silva. You create an empty Site Property and use a page to enter its value and encript it.

But in any scenario, before being able to use it in an application, you will have to decript it.
So, any developer/person with access to the code in the production environment will have access to this key, no matter what.



Thx for the answer!

I was hoping that it would be possible to create a specific application to mangae site properties from other applications there (this would make it easier for our release managers, as they would only have to go to that application to manage these). I can query the site properties from the System database ({Site_Property_Definition}) and even change them (actions are exposed on those tables), however I still have my original problem, where I don't see the actual value (not the default value) in the "{System}.Site_Property" table. Any ideas where the actual values are stored (the ones you enter in Service Center)?

I actually figured it out. i was looking in the wrong table. The values are stored in the {system}.Site_Property_Shared table.

Dirk Dooms wrote:

I actually figured it out. i was looking in the wrong table. The values are stored in the {system}.Site_Property_Shared table.

Be aware that if you change the value of a Site Property directly into the database, the value may not be updated for the applications, as the applications look for the value in the application cache and writting directly into database will not trigger a change in it (I think, but I may be wrong).

No, you are correct, I noticed that as well :)

I call the EspaceInValidateCache() function for the specific espace when changing a property. As we only change a property after deploy, or when a password changes, which isn't that often, the impact is very limited. 

my 2 cents, why not use a simple key-value table then?

when you actually are able to store the passwords hashed...

no cache-issues.

and no issues with storing passwords plain in the site-properties..