Feature Request: Support for Environment Variables in API Rules about pocketbase HOT 8 CLOSED

I'm closing this for now as I don't think it is a good idea.

This is easy to implement but I don't want to encourage usage of plain string comparison with env secrets (I assume that this is what you are doing) as it is prone to timing attacks and it is too easy to mess it up.

If there is enough demand for this I may reconsider it in the future, but for now remains out of the scope for v1.

from pocketbase.

What would be the use case for this?

from pocketbase.

My request came about from verifying a custom header from Stripe server-side functions, and duplicating the plain text ENV throughout several collections and various rules fields. giving the functions access to those collections, as I was running into issues of requests failing on the functions, due to duplicated requests canceling the logging in of a "server-side admin", and it was increasing round trip times on the server functions since it was passing data back and forth to login, then retrieving data, then manipulating data.

While yes I know you can disable duplicate request cancellation, the increased round-time is also why I moved to a ENV variable system, and my request comes from when updating an ENV_VAR, rather than having to paste the plain text string into each API rule, a singular location with the value that can be updated if need be would simplify managing secrets like that.

from pocketbase.

It seems that we posted at the same time. I'm sorry but I'm confused by your description (what is "Stripe server-side functions"?) and it is not clear to me why you want to do that.

Feel free to further elaborate with a more concrete example, but for now the request remains out of the scope.

from pocketbase.

Apologies if I was not clear before! I was trying to be brief but i'll go into more detail.

I am using SvelteKit API Endpoints for stripe webhook handling and additional stripe functionality like creating customers, creating checkouts, adding payment methods, things of that nature, and aspects of those are reflected back into the database.

My previous solution, of creating a custom admin only auth table with access to those collections using @request.auth.collectionName = "server_admins', this mostly worked, but would cause issues when multiple events happened in quick succession causing rejection errors due to auto cancellation of duplicate requests, which I know I can disable, but this also increased round trip time and bandwidth bloat as I was having to login in that admin first before being able to handle any of the incoming data, This also required storing the admin accounts username and password in environment variables on the server side.

I switched to a header token, where i added a custom header, using pb.beforeSend, and attached a custom validation token, and would then check it in the API Rules using a @request.headers.check_token = "LONG_TOKEN_STRING_HERE". and this long token string is copied into every API Rule that the API Endpoints are required to access and modify.

My request specifically is to allow the long token string to be stored in an environment variable system, in pocketbase that can be accessed through the API Rules, similar to my suggestion of @env.VARIABLE.

I am adapting a kind of technique from Supabase of a SECRET_KEY, allowing server functions to modify data as needed, but restricting it to only the tables i am allowing it to interface with using the request header token check and the API Rules.

If you need me to break down anything more or go into any more specifics do let me know and I would be happy to go into more detail and more use case specifications.

Note: I am not able to use the goja engine to do these as stripes libraries require node functionality.

from pocketbase.

Thank you for providing more details but as explained in #4854 (comment), comparing strings this way is prone to timing attacks and I don't want to encourage it or complicate the filter syntax by adding another const-time compare operator.

I still don't understand what is the purpose of the "server_admins" collection, but as an example for admin client you can check #3792 (reply in thread) (it is safe to have a single global instance in this case and the admin authentication can happen only once and the autoRefreshThreshold will take care to refresh the token if needed).

from pocketbase.

Okay I see, that makes sense, I will investigate those other options.

And just as a side note, the server_admins collection is a user collection that i just give full permissions on, on certain tables only, that way it restricts their access to certain collections, rather than a full PocketBase admin that would have full unrestricted access to everything, just to compartmentalize everything and keep track of where requests are coming from and restrict access if any issues arise.

Thank you for your time and insight.

from pocketbase.

In my case, I'm using Pocketbase on the client side with ouath2 and some collections, and only on the backend for sensitive collections (hashed password). I send the X-Pocketbase-Accesstoken in the header so that I can know if it's the backend or client. Of course, we don't expose the accesstoken on the client.

@request.auth.id = user.id && @request.headers.x_pocketbase_accesstoken = 'accesstoken' 

In the API rule, use it as above.

If the @env feature is implemented as suggested by the questioner in this topic, it will be easier to change the above accesstoken.

from pocketbase.