darrenbaldwin07 / clerk-rs Goto Github PK

The current default feature on reqwest uses native TLS which is harder to compile on some platforms.

It could either be switched to use rustls by default with a flag for native, or simply a flag for enabling rustls.

for example https://docs.rs/clerk-rs/latest/clerk_rs/apis/users_api/struct.User.html#method.get_user_list

limit and offset seem like they should be int

OragnizationMebership

The function get_user_list returns <Veccrate::models::User as seen here.
This is the User struct - https://docs.rs/clerk-rs/latest/clerk_rs/models/user/struct.User.html
However in clerk backend documentation, this is the response schema.
On comparison, i found that the User struct in clerk_rs does not have the following fields

• image_url
• has_image
• primary_web3_wallet_id
• saml_accounts
• delete_self_enabled
• create_organization_enabled

The azp claim may not always exist on the Clerk JWT. From the Clerk docs:

azp: authorized party - the Origin header that was included in the original Frontend API request made from the user. Most commonly, it will be the URL of the application. For example: https://example.com. This claim could be omitted if, for privacy-related reasons, Origin is empty or null.

This causes an error when decoding the JWT because azp is required in ClerkJwt: Error(Json(Error("missing field `azp`", line: 1, column: 185))).

When authorizing requests, instead of getting the JWKS from Clerk on every request, there should be some mechanism to cache the JWKS. clerk-rs could provide some common options (cached in memory, refresh on unknown kid, refresh periodically) and reasonable defaults and a trait to allow custom implementations.

Based on the documentation, Clerk seems to use i64 for timestamps.

After briefly reviewing the codebase, I've identified several instances of i32 timestamps:

• In email address verification:
  

  clerk-rs/src/models/email_address_verification.rs

  Line 20 in b47c950

  pub expire_at: Option<i32>,

• In the admin model, where it's also incorrectly wrapped in Option twice:
  

  clerk-rs/src/models/admin.rs

  Line 30 in b47c950

  pub expire_at: Option<Option<i32>>,

• In sign up:
  

  clerk-rs/src/models/sign_up.rs

  Line 101 in b47c950

  pub abandon_at: i32,

found a bug in the get_user function. Here is a snippet of the actual response from clerk:

...
"totp_enabled": false,
"backup_code_enabled": false,
"email_addresses": [
{
"id": "idn_xyz",
"object": "email_address",
"email_address": "[email protected]",
"reserved": false,
"verification": {
"status": "verified",
"strategy": "from_oauth_google",
"attempts": null,
"expire_at": null
},
"linked_to": []
}
],
"phone_numbers": [ ],
...

The value of email_addresses.verification.stratery is "from_oauth_google" however the only allowed value in clerk-rs is Admin - https://docs.rs/clerk-rs/0.1.8/clerk_rs/models/email_address_verification/enum.Strategy.html

I was trying to list all users via clerk_rs::apis::users_api::User::get_user_list, and the response deserialisation failed with this error:

Serde(
    Error(
        "unknown variant `email_code`, expected `admin` or `from_oauth_google`", 
        line: 1, 
        column: 754,
    )
)

Based on the Backend API docs, they have two variants of verification:

OTP	Admin
phone_code, email_code	admin

I also can't find the from_oauth_google variant.

https://docs.rs/clerk-rs/latest/clerk_rs/models/organization_membership/struct.OrganizationMembership.html

https://clerk.com/docs/reference/backend-api/tag/Organization-Memberships#operation/ListOrganizationMemberships

public_metadata | objectMetadata saved on the organization membership, accessible from both Frontend and Backend APIs
private_metadata | objectMetadata saved on the organization membership, accessible only from the Backend API

I'm not using actix so this is pulling in lots of extra dependencies.

To my understanding, for same-origin requests, authorization headers do not need to be passed because all the information is located in the __session cookie. So clerk_authorize should probably check to see if you have a session cookie or maybe check based off of some sort of configuration.

My assumption is that this will be worked on at some point. Honestly this repo is a godsend, just wondering if I'm correct and that this will be changed or if I have to make own Middleware.