current_user variable in back function

fmvalsera

Hi REI3 Team!

trying to get the name of the current user executing a back function (I don't know if there is a better way to do it), I wrote something like this:

$BODY$ DECLARE current_user TEXT; BEGIN SELECT name INTO current_user FROM instance.login WHERE id = instance.get_user_id(); ...
I was expecting "admin" as the right value for the "current_user" variable since it is the login/user executing the function, but I'm getting "rei3" instead which is the user I'm using to access the Postgres database.

After changing the name of the variable from "current_user" to "user_name" or whatever I'm getting the expected value "admin".

Is there any implicit variables which are accessible from back functions or something is overriding/misbehaving? I did't find anything about this in documentation.

Thanks!

fmvalsera

Regarding to this issue, I posted it yesterday and then hid it because I realized I needed some time to verify the behavior and give more accurate information.

I have wrote 2 back functions:

1. The first one returns the "current_user" variable as it is (although the return type of the function is TEXT):

The result in this case is "admin" (as expected).

2. The second one returns the "current_user" variable after casting the value to TEXT (also the return type of the function is TEXT):

But in this case the result is "rei3" (the user to connect to the database !?)

Well, I don't know well the details of the PL/PgSQL language but I would say that the result should be the same in both cases, right?

Thanks in advance for helping me to clarify this.
Regards.

gabriel

CURRENT_USER is a constant in Postgres, it always contains the name of the user connecting to the database. To avoid using constants or other protected names, you can use a prefix for your variable names such as _current_user.

Regarding your initial issue: Are you building your own apps or are you building on top of apps like lsw_organizations? In the later case, you´d only need to store the user ID (from instance.get_user_id()) and then you´d be able to lookup the lsw_organizations.contact via the attribute login to get the name of the affected user.

If you build your own app, you might want to execute a user sync - this will sync all user meta data from the instance (eg. admin panel in this case) to a relation inside your own app. Then you always have all the user data inside your own app and can reference and display it as you wish.

Warning: Please never access any instance or app tables directly. If you cannot access via an instance function, it is not protected against change in the future and will eventually break. That is why we have features like the user sync to safely copy relevant data to where you have access to (eg. inside your own app).

fmvalsera

gabriel

Thanks a lot for your "speed of light" reply (as always 😃 ). Everything is clear now, I thought that the back functions were executed in a sandbox of REI3 or similar (like in front functions with JS). But according with your comments all the power of PL/PgSQL running in Postgres is available in back functions. That's really great!

At the moment I just needed the name of the user as a reference, but I will check the new user sync functions for this task. Although the dependency with lsw_organizations could be easier I'd prefer to limit this for the time being.

Have a nice day!

gabriel

There is absolutely no need to build on lsw_organizations - its just easy to address this issue if you had done so for any reason.

A sandbox would have been useful, but does not exist in the context of our backend functions. We might split up user access to the database in the future to limit access for different purposes. But at the moment, your DB user has full access and can do whatever. Not amazing security wise, but at least users only have access via backend functions which are controlled by the author.