Page MenuHomeDevCentral

WIP: API key

Authored by dereckson on Sep 27 2021, 21:50.



Diff Detail

rLF Limiting Factor
Lint OK
No Unit Test Coverage
Build Status
Buildable 3793
Build 4043: arc lint + arc unit

Event Timeline

dereckson created this revision.

This change can only live if we provide a way to fill metadata.

A trait object? A callback function?

For example, for Onyx Docs, we'd like to map an API key to an user, following the api key field of the Users table, but we could imagine a case where:

  • OAuth authentication is used
  • several keys are generated, maintained in a separate table

The first case would be covered by an attribute like [#TableMap("Users", User, "api_key"], to allow a generic behavior mapping a SQL query SELECT * FROM <table> WHERE <field> = <value> to a struct <type> (with here #TableMap providing <table>, <type> and <field>).

The other cases are less easy to map.

Sometimes, the API key will be managed by a service mesh and not by the application, and mapping between an user and the key would become the selection of the user from an user id provided by an header added by the service mesh (we could for example imagine a service mesh with a guard adding X-API-AUTHENTICATED: true and X-API-USER: 121000211 to the requests).

That makes me reluctant to offer a lot of automation.

To provide the type without an implementation won't be useful as to use it as a guard in Rocket, the application should impl FromRequest for APIKey, but can't: that behavior is reserved to the crates defining FromRequest (rocket) and APIKey (limiting-factor). A callback function would solve that issue nicely.


This structure is currently Sized, as String and HashMap are.

If we add something like pub from_request_callback: Fn(...),, it won't be anymore, so callback could be difficult here.

The FromRequest trait requires the type to be Sized.

Per previous comment.