neoeinstein / aliri Goto Github PK
View Code? Open in Web Editor NEWWeb API access control for Rust
License: Apache License 2.0
Web API access control for Rust
License: Apache License 2.0
RFC 6750 Section 1.1 indicates:
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
In section 2.1, the RFC indicates the syntax for the credentials as:
b64token = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token
In no way does the RFC indicate that the scheme may be interpreted as case-insensitive. Right now aliri_reqwest
produces credentials using bearer
. This should be altered to Bearer
to be compliant with the RFC.
Right now, the automatic JWKS refresh from aliri_oauth2 will attempt to pass back received etag
and last-modified
header data to the JWKS endpoint in order to avoid unnecessary data transfer when the JWKS hasn't changed. We can also do some interpretation of the cache-control
headers to ensure that we do not refresh faster than the max-age
directive in that header. We will still want to use a static, passed in refresh time and use the maximum of those two values when deciding when to next refresh the JWKS.
We opt not to only use the max-age
directive because that can lead to excessive refreshes on endpoints that do not often have changes, where the immediacy of those changes is not as important. This can lead to rate limiting of requests for distributed systems with many verifiers. Two scenarios appear to drive a desire for quick refreshes:
For the first scenario, the delay between introducing a new signing token and beginning to use it for signing purposes should be at least the amount of time it takes all validators to have refreshed the JWKS. I am not convinced that a new signing token must be activated as soon as possible after it is introduced. Generally, a new token can be introduced minutes to hours in advance, so cleaving too tightly to the max-age
is not necessary to achieve this objective.
For the second scenario, the delay before a signing key can be safely removed from the JWKS is limited by the maximum validity period of any token issued using that signing key. This has little to no relation to the max-age
directive.
There may be other scenarios beyond those listed above. If you have any additional scenarios not called out above, add them as a comment to this issue.
There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.
Error type: Cannot find preset's package (github>neoeinstein:semver/breaking/unstable)
This can allow for the propagation and use of distributed tracing contexts through these operations.
dotenv is Unmaintained
Details | |
---|---|
Status | unmaintained |
Package | dotenv |
Version | 0.15.0 |
URL | dotenv-rs/dotenv#74 |
Date | 2021-12-24 |
dotenv by description is meant to be used in development or testing only.
Using this in production may or may not be advisable.
The below may or may not be feasible alternative(s):
See advisory page for additional details.
Now, when declaring an access policy by scope, it is not possible to get the fields of the standard implementation of BasicClaimsWithScope
from the final structure without defining your own implementation of jwt::CoreClaims
, namely those that are in jwt::BasicClaims
.
Expected:
scope_policy!(Profile / ProfileScope; "profile");
#[get("/")]
async fn endpoint(token: Profile) -> impl Responder {
println!("Token subject: {}", token.claims().sub);
HttpResponse::Ok()
}
Actual:
#[derive(Clone, Debug, Deserialize)]
pub struct CustomClaims {
iss: jwt::Issuer,
aud: jwt::Audiences,
sub: jwt::Subject,
exp: Option<UnixTime>,
nbf: Option<UnixTime>,
scope: scope::Scope,
}
impl jwt::CoreClaims for CustomClaims {
fn nbf(&self) -> Option<UnixTime> { self.nbf }
fn exp(&self) -> Option<UnixTime> { self.exp }
fn aud(&self) -> &jwt::Audiences { &self.aud }
fn iss(&self) -> Option<&jwt::IssuerRef> { Some(&self.iss) }
fn sub(&self) -> Option<&jwt::SubjectRef> { Some(&self.sub) }
}
impl scope::HasScope for CustomClaims {
fn scope(&self) -> &scope::Scope { &self.scope }
}
scope_policy!(Profile / ProfileScope(CustomClaims); "profile");
#[get("/")]
async fn endpoint(token: Profile) -> impl Responder {
println!("Token subject: {}", token.claims().sub);
HttpResponse::Ok()
}
I'm using aliri-axum
/aliri-tower
, and can't find a way to "whitelist" a route, in order for it to stop checking for authentication. This is especially useful for a "login" route, but there's more than one route in my application that should be public to those unauthorized. However, even if I completely omit the scope from a handler's signature, it still returns aliri_tower::OnJwtError::on_missing_or_malformed
.
In other words, I would like to be able to open some - but not all - routes to people without bearer tokens. Am I missing how to do this?
In theory, even forks cannot be created for this project until it has a license
failure is officially deprecated/unmaintained
Details | |
---|---|
Status | unmaintained |
Package | failure |
Version | 0.1.8 |
URL | rust-lang-deprecated/failure#347 |
Date | 2020-05-02 |
The failure
crate is officially end-of-life: it has been marked as deprecated
by the former maintainer, who has announced that there will be no updates or
maintenance work on it going forward.
The following are some suggested actively developed alternatives to switch to:
See advisory page for additional details.
Even if multiple algorithms are offered, the deserialization of the response will fail if any unsupported algorithm is offered.
My Keycloak server provides both RS256 and RSA-OAEP algorithms.
Running
let authority =
aliri_oauth2::Authority::new_from_url("https://example.com/auth/realms/master/protocol/openid-connect/certs", oauth_validator)
.await?;
fails with
Error: error decoding response body: data did not match any variant of untagged enum Algorithm at line 1 column 90
with column 90 containing "alg": "RSA-OAEP"
spin is no longer actively maintained
Details | |
---|---|
Status | unmaintained |
Package | spin |
Version | 0.5.2 |
URL | mvdnes/spin-rs@7516c80 |
Date | 2019-11-21 |
The author of the spin
crate does not have time or interest to maintain it.
Consider the following alternatives (both of which support no_std
):
conquer-once
lock_api
(a subproject of parking_lot
)
spinning_top
spinlock crate built on lock_api
See advisory page for additional details.
stdweb is unmaintained
Details | |
---|---|
Status | unmaintained |
Package | stdweb |
Version | 0.4.20 |
URL | koute/stdweb#403 |
Date | 2020-05-04 |
The author of the stdweb
crate is unresponsive.
Maintained alternatives:
See advisory page for additional details.
Hi,
i couldn't find how to use custom Headers and decompose together. Using the naive approach
#[derive(Clone, Debug, serde::Serialize, serde::Deserialize)]
pub struct AbcHeaders {
pub alg: Algorithm,
pub jwk: Jwk,
pub nonce: String,
pub url: String
}
let decomp = token.decompose::<AbcHeaders>().unwrap();
didn't allow me to access the content of the AbcHeaders. Also implementing a trait for Decomposed does not work as self.header is inaccessible as its pub(crate).
Am i missing something obvious?
When compiling for a Windows target (like x86_64-pc-windows-gnu
), aliri_tokens/src/sources/file.rs:40:14
is flagged up as a compilation error, since .mode()
is only implemented on Unix systems and therefore doesn't exist in OpenOptions
for Windows targets.
For OIDC-compliant issuers, the token URL can be inferred from the Issuer
using the well-known OIDC configuration endpoint.
Use-after-free in BodyStream due to lack of pinning
Details | |
---|---|
Package | actix-http |
Version | 1.0.1 |
URL | actix/actix-web#1321 |
Date | 2020-01-24 |
Patched versions | >= 2.0.0-alpha.1 |
Affected versions of this crate did not require the buffer wrapped in BodyStream
to be pinned,
but treated it as if it had a fixed location in memory. This may result in a use-after-free.
The flaw was corrected by making the trait MessageBody
require Unpin
and making poll_next()
function accept Pin<&mut Self>
instead of &mut self
.
See advisory page for additional details.
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These branches will be created by Renovate only once you click their checkbox below.
These updates are awaiting their schedule. Click on a checkbox to get an update now.
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
aliri/Cargo.toml
aliri_braid 0.4.0
once_cell 1.19
regex 1
ring 0.17
serde 1
serde_json 1
tracing 0.1
thiserror 1
openssl 0.10
color-eyre 0.6
tracing-test 0.2.4
aliri_actix/Cargo.toml
actix-web 4
futures 0.3
once_cell 1.19
serde 1
thiserror 1
tracing 0.1
actix-rt 2
actix-web 4
color-eyre 0.6
regex 1
serde_json 1
aliri_axum/Cargo.toml
axum-core 0.4.3
http 1.1.0
once_cell 1
aliri_braid 0.4.0
axum 0.7.5
color-eyre 0.6.3
reqwest 0.12.3
serde 1.0.197
serde_json 1
time 0.3.36
tokio 1
tracing 0.1
tracing-subscriber 0.3.18
aliri_base64/Cargo.toml
base64 0.22
serde 1
serde 1
serde_json 1
aliri_clock/Cargo.toml
serde 1
aliri_macros/Cargo.toml
serde 1
aliri_oauth2/Cargo.toml
aliri_braid 0.4.0
arc-swap 1.7
compact_str 0.7.1
reqwest 0.12
serde 1
thiserror 1
tokio 1
tracing 0.1.40
openssl 0.10
serde_json 1
tokio 1
aliri_reqwest/Cargo.toml
async-trait 0.1.79
bytes 1.6.0
http 1.1.0
predicates 3.1.0
reqwest 0.12.3
reqwest-middleware 0.3.0
tracing 0.1
tokio 1
aliri_tokens/Cargo.toml
aliri_braid 0.4.0
async-trait 0.1.79
rand 0.8.5
reqwest 0.12
serde 1
serde_json 1
thiserror 1
tokio 1
tracing 0.1.40
clap 4.5.4
color-eyre 0.6
dotenvy 0.15.7
tracing-subscriber 0.3
tokio 1
aliri_tower/Cargo.toml
bytes 1.6.0
http 1.1
http-body 1.0
serde 1
thiserror 1
tracing 0.1
tower-layer 0.3.2
tower-http 0.5
axum 0.7
tokio 1
aliri_warp/Cargo.toml
serde 1
thiserror 1
tracing 0.1
warp 0.3
color-eyre 0.6
regex 1
serde_json 1
tokio 1
.github/workflows/release-please.yml
google-github-actions/release-please-action v4@e4dc86ba9405554aeba3c6bb2d169500e7d3b4ee
actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29
dtolnay/rust-toolchain stable
ubuntu 22.04
.github/workflows/rust.yml
actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29
dtolnay/rust-toolchain nightly
dtolnay/rust-toolchain stable
Swatinem/rust-cache v2@23bce251a8cd2ffc3c1075eaa2367cf899916d84
actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29
dtolnay/rust-toolchain stable
Swatinem/rust-cache v2@23bce251a8cd2ffc3c1075eaa2367cf899916d84
taiki-e/install-action nextest
actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29
dtolnay/rust-toolchain miri
Swatinem/rust-cache v2@23bce251a8cd2ffc3c1075eaa2367cf899916d84
actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29
dtolnay/rust-toolchain stable
Swatinem/rust-cache v2@23bce251a8cd2ffc3c1075eaa2367cf899916d84
ansi_term is Unmaintained
Details | |
---|---|
Status | unmaintained |
Package | ansi_term |
Version | 0.12.1 |
URL | ogham/rust-ansi-term#72 |
Date | 2021-08-18 |
The maintainer has adviced this crate is deprecated and will not
receive any maintenance.
The crate does not seem to have much dependencies and may or may not be ok to use as-is.
Last release seems to have been three years ago.
The below list has not been vetted in any way and may or may not contain alternatives;
See advisory page for additional details.
Right now, the creator of an Authority
needs to know the JWKS URL for the issuing authority. However, for OIDC-compliant issuers, this can be inferred from the issuer itself. Add a creation method that pulls the JWKS URL from the well-known OIDC configuration endpoint (inferred from the issuer), and refreshes the configuration endpoint periodically to ensure that any updates to the JWKS URL are also tracked (this should be rare).
When using Authority::new_from_url
with the reqwest
feature in aliri_oauth2, the feature by default does not enable any TLS. This can lead to errors such as
reqwest::Error {
kind: Request,
url: Url {
scheme: "https",
cannot_be_a_base: false,
username: "",
password: None,
host: Some(Domain("example.com")),
port: None,
path: "/.well-known/jwks.json",
query: None,
fragment: None
},
source: hyper::Error(Connect, "invalid URL, scheme is not http")
}
This error can be avoided by users specifying reqwest features to use in their own Cargo.toml, i.e.
reqwest = { version = "0.11", default_features = false, features = ["default-tls"] }
But this workaround is not immediately obvious. Users also need to make sure that the version they specify is in sync with aliri manually.
While this currently does allow users to choose the TLS library to use, a better solution might be to allow users to specify the type of TLS they would like supported through feature flags on aliri_oauth2, which can then be passed through to the reqwest feature flags inside the aliri-oauth2 Cargo.toml.
net2
crate has been deprecated; usesocket2
instead
Details | |
---|---|
Status | unmaintained |
Package | net2 |
Version | 0.2.34 |
URL | deprecrated/net2-rs@3350e38 |
Date | 2020-05-01 |
The net2
crate has been deprecated
and users are encouraged to considered socket2
instead.
See advisory page for additional details.
data did not match any variant of untagged enum MaybePrivate
The above error results from any JWK deserialization that fails to deserialize as a signer, but- unfortunately- this can be with correct JSON and semantically invalid key values. When this is the case, it's almost impossible to determine programmatically what field was the source of the issue.
It may be worth separating parsing and validation such that a pseudo-JWK can be deserialized, then use a separate error type in the process of validating its key values, turning it into a "true" JWK instance.
Axum has had a number of api changes in 0.7 which make this crate incompatible.
Use-after-free in Framed due to lack of pinning
Details | |
---|---|
Package | actix-codec |
Version | 0.2.0 |
URL | actix/actix-net#91 |
Date | 2020-01-30 |
Patched versions | >= 0.3.0-beta.1 |
Affected versions of this crate did not require the buffer wrapped in Framed
to be pinned,
but treated it as if it had a fixed location in memory. This may result in a use-after-free.
The flaw was corrected by making the affected functions accept Pin<&mut Self>
instead of &mut self
.
See advisory page for additional details.
See more info on why here: https://crypto.stackexchange.com/questions/95878/does-the-signature-length-of-rs256-depend-on-the-size-of-the-rsa-key-used-for-si
Is short, RSA256 means 256-byte hashes, not keys.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.