PR Type

Feature + Refactor

PR Checklist

• [x] Tests for the changes have been added / updated.
• [x] Documentation comments have been added / updated.
• [x] A changelog entry has been made for the appropriate packages.
• [x] Format code with the latest stable rustfmt.

Overview

This PR introduces significant breaking changes for actix-session and actix-redis. For actix-redis:

• RedisSession is removed to be moved into actix-session (renamed and reworked into RedisActorSessionStore).
• Updated redis-async from 0.8 to 0.12.

For actix-session, this is basically a rewrite. Key changes:

• SessionMiddleware now requires to explicitly specify the storage backend for the session state. This makes sure that a storage backend is always present when SessionMiddleware it's used. Users no longer have to make sure to wrap the backend and the middleware in the right order.
• We introduce a SessionStore trait to empower users to define their own custom storage backends for session state. All the logic associated with the session cookie is baked into SessionMiddleware, significantly reducing the amount of logic required to support a new backend - i.e. library authors just need to specify how to perform CRUD operations. This is a significant improvement with respect to the previous iteration of this crate - both CookieSession and RedisSession were previously re-implementing the same cookie-handling logic.
• Three storage backends are implemented out of the box, behind features flags: RedisActorSessionStore, RedisSessionStore (with TLS support), CookieSessionStore.
• Tightened the methods exposed on Session to prevent users from being able to corrupt the session state by setting fields to string values that are not valid JSON (i.e. set_session is now private).

… processing based on the request, and the presence or absence of credentials.

This is a breaking change compared to the current implementation The validation function is now defined as Fn(ServiceRequest, Option<T>) -> O instead of Fn(ServiceRequest, T) -> O. This allows to cater for cases where e.g. some routes don't require authentication, or some other application-specific authorization logic.

Another approach could be to add a middleware setting to decide whether to abort the request if there is no credentials present in the request.

PR Type

Update

PR Checklist

Check your PR fulfills the following:

• [x] Tests for the changes have been added / updated.
• [ ] Documentation comments have been added / updated.
• [x] A changelog entry has been made for the appropriate packages.
• [x] Format code with the latest stable rustfmt

Overview

The goal was to updated all dependencies to work with the latest actix-web beta and fix all the tests. There is one previews test failure in session::test::test_session_workflow which I did not fix.

Hello!

I was wondering if there is any support for body/JSON content when the Authorization: Bearer <token> header is missing. I have the following HttpAutentication when creating the server app:

HttpServer::new(move || {
        let auth_validator = HttpAuthentication::bearer(jwt_validate);
        App::new()
            .wrap(Logger::default())
            .wrap(auth_validator)
            .service(responders::hello)
}).bind("127.0.0.1:80")?.run().await?;

The jwt_validate function is:

async fn jwt_validate(req: ServiceRequest, credentials: BearerAuth) -> Result<ServiceRequest, Error> {
    if req.path().starts_with("/api/v1/auth") {
        return Ok(req)
    }
    let parsed = match auth::decode_token(credentials.token().into()) {
        Ok(val) => val,
        Err(err) => return Err(Error::from(err))
    };
    match auth::validate_jwt(parsed) {
        Ok(_val) => Ok(req),
        Err(err) => return Err(Error::from(err))
    }
}

This works fine (access is granted when the token is correct and access is denied when it's not), but when I don't use the header Authorization: Bearer <token> I just get a 401 Unauthorized code with an empty body. Is there a way of adding a custom JSON body to the 401 Unauthorized error response using actix-web-httpauth?

Thanks in advance!

using actix-session like this

.wrap(
    CookieSession::signed(&decode(env::var("APP_KEY").unwrap()).unwrap())
        .domain(env::var("APP_URL").unwrap())
        .name("queue_rs")
        .path("/")
        .secure(false),
)

results in

error[E0277]: the trait bound `CookieSession: Transform<actix_web::app_service::AppRouting, ServiceRequest>` is not satisfied
   --> src/main.rs:268:17
    |
268 | /                 CookieSession::signed(&decode(env::var("APP_KEY").unwrap()).unwrap())
269 | |                     .domain(env::var("APP_URL").unwrap())
270 | |                     .name("queue_rs")
271 | |                     .path("/")
272 | |                     .secure(false),
    | |__________________________________^ the trait `Transform<actix_web::app_service::AppRouting, ServiceRequest>` is not implemented for `CookieSession`

deps: actix-web = "4.0.0-beta.1" actix-rt = "2.0.0-beta.1" actix-files = "0.6.0-beta.1" actix-session = "0.4.0"

Also great job on the tokio upgrade, i see you guys have been working hard to get that upgraded.

PR Type

Bug Fix

PR Checklist

Check your PR fulfills the following:

• [x] Tests for the changes have been added / updated.
• [x] Format code with the latest stable rustfmt

Overview

Make it work with latest beta of actix-web. ~~Requires https://github.com/actix/actix-web/pull/2168~~

PR Type

Refactor

PR Checklist

Check your PR fulfills the following:

• [x] Format code with the latest stable rustfmt

Overview

Update dependencies to use crates with Tokio 1.0.

PR Type

Bug Fix

PR Checklist

• [x] Tests for the changes have been added / updated.
• [x] Documentation comments have been added / updated.
• [x] A changelog entry has been made for the appropriate packages.
• [x] Format code with the nightly rustfmt (cargo +nightly fmt).

Overview

Closes #244

Expected Behavior

Be able to use HttpAuthentication::bearer and actix-cors in the same project

Current Behavior

Hi, I am trying to use HttpAuthentication::bearer in a project that also uses actix-cors, if I use HttpAuthentication::bearer or actix-cors alone it works fine, but if I use both I get an error saying that cors has block the request due to No 'Access-Control-Allow-Origin' header is present on the requested resource.

Steps to Reproduce (for bugs)

My code is:

#[actix_rt::main]
pub async fn init() -> std::io::Result<()> {
 let port = env::var("PORT").unwrap_or_else(|_e| "8000".to_string());
 let mut socket = "127.0.0.1".to_string();
 socket.push(':');
 socket = socket + &port;
 let db_state = db_mongodb::DB::init().await;

 HttpServer::new(move || {
    App::new()
        .wrap(
            Cors::permissive()
        )
        .data(db_state.clone())
        .service(
            web::scope("/api")
            .wrap(HttpAuthentication::bearer(auth::validator))
            .configure(routes::init_secured)
        )
        .service(
            web::scope("/public")
            .configure(routes::init_public)
        )
 })
 .bind(socket).unwrap()
 .run()
 .await
}

Your Environment

• Rust Version: rustc 1.47.0 (18bf6b4f0 2020-10-07)
• actix-web = "3.2.0"
• actix-rt = "1.1.1"
• actix-web-httpauth = "0.5.0"
• actix-cors = "0.5.1"
• Operating System: Debian GNU/Linux 10 (buster)
• Kernel: Linux 4.19.0-12-amd64
• Architecture: x86-64

We are observing that our actix-web application occasionally panics under a lot of contention with the message "AuthenticationMiddleware was called already". This seems to come from here https://github.com/actix/actix-web-httpauth/blob/v0.4.0/src/middleware.rs#L184

We have recently migrated to actix-web 2.0 and actix-web-httpauth 0.4. We haven't observed this before the migration.

As this doesn't happen for all requests, there seems to be some race condition either within actix-web or actix-web-httpauth that causes this.

We use bearer token authorization and within the validation function, to validate the token, we just perform an HTTP request with reqwest and depending on the result return Ok or Err.

Expected Behavior

If I have app.example.com as a whitelisted Origin but both the backend + frontend is loaded from app2.example.com, request should be allowed.

Current Behavior

If I have app.example.com as a whitelisted Origin but both the backend + frontend is loaded from app2.example.com, requests are blocked, even though Host + Origin is the same. Browsers allow these requests to happen (no OPTIONS request sent, as Origin + Host is the same), but actix_cors decides to forcefully block the request.

Relevant code from actix_cors:

https://github.com/actix/actix-extras/blob/1561bda82268931edb070501413a46337ed71290/actix-cors/src/inner.rs#L73-L99

Possible Solution

actix_cors should not forcefully cancel/error on requests where Origin and Host is the same header. In fact, if there is no OPTIONS request, actix_cors should not care about the actual request at all, besides setting the right headers on the Response. As it stands today, actix_cors is trying to be overly protective of responses while it doesn't add anything regarding security.

Expected Behavior

To not store a string as string wrapped in a string. (extra double quotes). Unsure if there's some magic I haven't seen to prevent this.

https://github.com/actix/actix-extras/blob/master/actix-session/src/session.rs#L136-L147 We should check if the value is a string. If it's a string we should not use serde_json::to_string

Current Behavior

Using serde_json::to_string on everything including values of type string

Possible Solution

it seems there may have been uniformity reasons for not allowing types other than strings being stored, but I believe this makes the middleware less useful and more awkward.

Steps to Reproduce (for bugs)

1. using redis middleware insert a session value

Context

Double stringified strings result in all those values needing to be doubly unwrapped which is awkward. Would be nice to let users decide what kind of values they want to store and not wrap everything as string.

Your Environment

• Rust Version (I.e, output of rustc -V):
• Actix-* crate(s) Version: Latest stable.

PR Type

INSERT_PR_TYPE: Code Style: Cargo.toml Feature: Session Key Extraction ability.

PR Checklist

• [ ] Tests for the changes have been added / updated.
• [ ] Documentation comments have been added / updated.
• [ ] A changelog entry has been made for the appropriate packages.
• [ ] Format code with the nightly rustfmt (cargo +nightly fmt).

Overview

The goal is add this feature to be utilized by the redis session middleware without breaking any other session middleware.

Notes from discussion: https://github.com/actix/actix-extras/issues/306

Dev Notes: This is not a working PR, changes will come after feedback.

Discussed in https://github.com/actix/actix-extras/discussions/305

.wrap(SessionMiddleware::new(
    RedisActorSessionStore::new(redis_conn.clone()),
    secret_key.clone(),
))

session.insert("userid", id).expect("id inserted");

Creating a Cors middleware requires configuration in some cases. That needs testing.

However, it is pretty hard to test a created Cors instance as it doesn't expose its values.

Expected Behavior

Be able to test a Cors instance for its values.

Current Behavior

Not possible. It is possible to render a debug string of the struct, however as it uses HashSet with RandomStates, instances containing HashSet values can't be tested.

Possible Solution

Have Cors implement PartialEq. Or allow access to the values of its Inner.

Steps to Reproduce (for bugs)

1. Set up a Cors instance
2. Try to test it.

Context

Your Environment

• Rust Version (I.e, output of rustc -V):
• Actix-* crate(s) Version:

PR Type

Feature

PR Checklist

• [x] Tests for the changes have been added / updated.
• [x] Documentation comments have been added / updated.
• [x] A changelog entry has been made for the appropriate packages.
• [x] Format code with the nightly rustfmt (cargo +nightly fmt).

Overview

Implemented Sqlite session backend. The database/table will get created automatically if they don't exist.

Default garbage collection of stale sessions happens through a database trigger. (it can be turned off and the trigger will be dropped, and garbage collection can be implemented outside if needed.)

PR Type

Feature

PR Checklist

• [x] Tests for the changes have been added / updated.
• [x] Documentation comments have been added / updated.
• [x] A changelog entry has been made for the appropriate packages.
• [x] Format code with the nightly rustfmt (cargo +nightly fmt).

Overview

In order to let crates in the actix web ecosystem interact correctly with actix_web::Error, this commit introduces its own error type, replacing the previous usage of anyhow::Error.

This will break any consumer code that depends on the presence of anyhow::Error, but in exchange it will allow more users of actix-identity to leverage its public API inside responders with less work.

Closes #272