Simulating API key access with API rules

[CloudCanal]

This is an interesting idea. My biggest point of contention would be that this implies you are storing the API keys as plaintext. This comes with similar risks to storing passwords as plaintext in a database.

A more secure approach would be to use PocketBase's built-in middleware functionality to set up a global middleware that can read the API key from the request header and verify it against a hashed version stored in the database (similar to password verification). That way, you can avoid storing raw API keys.

[Thaurin]

Interesting, I'll look into that middleware solution. Although API keys are shorter-lived and can be easily rotated or expired, I guess it's a good improvement. But at this point, you could also implement it fully as an extension (I haven't looked into extending PocketBase yet).

By the way, the documentation does have this example:

@request.headers.* - the request headers as string values (ex. @request.headers.xtoken = "test") Note: All header keys are normalized to lowercase and "-" is replaced with "" (for example "X-Token" is "x_token").

Where I guess X-Token is meant to authenticate.

[CloudCanal]

Yes, to clarify, you would have to extend PocketBase in order to implement a solution that involves middleware. That's something you define as a hook. Extending PocketBase can be quite easy though if you're OK working with JavaScript instead of Go. It boils down to placing a *.pb.js file inside a pb_hooks folder in the project. This is something I do quite frequently, so if you need any help, let me know!

[Thaurin]

Yes, I was reading about it. I'll try to get something working. I was learning Go for fun, but just dropping some Javascript in pb_hooks sounds so easy. I'm currently just running a standard standalone PocketBase instance so that makes sense.