(un)expected behavior of 'Session' when registering services from dynamically loaded libs

[be-mevsane]

Hi all,
I've been trying out ntex and enjoying myself quite a bit already, honestly appreciate your work!

I found the docs on ntex::web::App::configure and wondered if that would also work with shared libraries.

My idea was to

1. define the services only inside the shared libraries using both web::resource or the proc_macros web::get etc.
2. export a loader_function that registers the services
3. import the loader_function before setting up the server and passing the cfg argument to it

This kinda worked out great. The paths are all accessible and return the defined HttpResponse. The logger wrapper is working properly and enabling/disabling the services can be handled by the shared libraries.

Problem with shared libs

• Registering the services from the same crate (same or different module as the web::App construction) makes proper use of the session. Read/Write for session works just fine.
• Registering the services from a shared library on the other hand can't seem to make use of the session. The session always returns None for any variable, even though the request is incoming with the expected cookies. Contrary to the wrapper for the logger, which works just fine. So it is not a wrapper problem I assume.

Initial thoughts
Maybe it is related to the inner type of ntex_session::Session? pub struct Session(Rc<RefCell<SessionInner>>);
But SessionInner is both reference counted and allows for "a mutable memory location with dynamically checked borrow rules" (quoted RefCell docs).
My expectation would be that the session should also work with registered services via the shared library approach.

If anyone has a clue on why the session is not working and if that is expected behavior, please clarify. I'd really appreciate it!
I could also write my own Middleware that takes care of this issue, but that's not the point. I'd like to understand this behavior since I'm just learning rust and ntex.

---

Defining the loader_function could look something like this:

• index same as in User sessions
• welcome same as in basic welcome

fn loader_function(&self, cfg: &mut web::ServiceConfig) -> () {
  cfg
    .service(index)
    .service(welcome);
}

Loading the loader_function might look like this:

...
let library = Rc::new(Library::new("library_path")?);
let loader_function = unsafe { library.get::<fn(&mut web::ServiceConfig) -> ()>("loader_function") };
// accounting for proper capture and thread safety is ommited for simplicity sake
...
web::App::new()
  // enable logger 
  .wrap(middleware::Logger::default())
  // cookie session middleware
  .wrap(CookieSession::signed(&[0; 32]).secure(false))
  //.service(index) - register service via loader_function instead
  //.service(welcome) - register service via loader_function instead
  .configure(|cfg: &mut web::ServiceConfig| {
    loader_function(cfg);
  })
...

I've checked the cookies via both when directly registering the services and independently using the shared library:

- println!("{:?}", req);   // just print out the request
- curl -X GET localhost:8080/ -b cookies.txt -c cookies.txt   // call the 'index' service
- curl -X GET localhost:8080/welcome -b cookies.txt -c cookies.txt   // call the 'welcome' service

[fafhrd91]

you cannot specify middleware in web::ServiceConfig. in general, middlewares get composed at compile time, you can try to create custom middleware and configure it use something from dynamic library. but in any case middleware must be specified with App::wrap()

[be-mevsane]

Thats generally a good point and as you can see in my snippet, I used .wrap(CookieSession::signed(&[0; 32]).secure(false)) outside of .configure.
Sadly this does not answer the behavior of CookieSession being parsed for services from the same crate but not from shared libraries.
Whereas the middleware for Logger works just fine for both.

[be-mevsane]

After some more digging I came up with a potential reason (not a fix!) why that happens...
Since Session(Rc<RefCell<SessionInner>>) uses RefCell to share data from request start to finish with the called service handler, I've decided to check for the address of SessionInner::state.

There are three locations where the address has to match:

1. inside CookieSessionMiddleware::call invoking Session::set_session before ctx.call
2. inside the service handler /welcome when calling session.set
3. inside CookieSessionMiddleware::call invoking Session::get_changes after ctx.call

service handler loading type	location 1	location 2	location 3	node
same crate	0x7f463800a308	0x7f463800a308	0x7f463800a308	all match
shared lib	0x7f462c00a308	0x7f462c00a798	0x7f462c00a308	location 2 differs!

It seems like that a service handler loaded via shared lib receives a different SessionInner reference than what CookieSessionMiddleware::call provides.

Maybe there is some move magic going on at Session::from_request...

I am unable to demangle how the #[proc_macro_attribute] #[web::get("/welcome")] constructs the handler and how the handler receives its arguments by the FromRequest implementations. Maybe this can lead me towards the solution. Any suggestions appreciated!

[be-mevsane]

It seems like the problem was related to inconsistent TypeId between loader library and dynamically loaded lib.

Calling TypeId::of::<Rc<RefCell<SessionInner>>>() resulted in different values, which in turn prevented finding an already existing Session via Session::get_session and created a new Session object with a new address.

Now it's up to figuring out on matching them.

[fafhrd91]

wow, i wouldn’t think about this possibility. i am not sure how to fix this

[be-mevsane]

With a lot of trial and error, I finally got it to work now... There are actually two possible solutions to this:
I'd really appreciate opinions regarding these.

A. Provide custom generic method including a hashing function to insert and get from the extentions inner HashMap

This kinda impacts performace just slightly, but depends if the function is const or not. I used a CustomTypeId struct and used std::any::type_name::() for my unique identifier as a quick test. Tested this by adding the path property inside the Cargo.toml to a local copy of all ntex libs. Even though the docs say for type_name that it is best-effort, it worked out fine generating identical names.
A better approach would be generating a custom generic compile time hashing method, if all possible extentions are known and fixed.

B. Split the dependencies between main-crate and loaded-crate

 main-crate    // this loads the shared libs
 shared-crate  // all shared definitions are here
 loaded-crate  // this outputs a shared lib

• main depends on shared
• loaded depends on shared
  -> Both now import needed symbols by going through shared-crate first e.g. shared_crate::ntex::web etc.

Important Notes

• B might stop working when the other dependencies between main-crate and loaded-crate differ due to the memory alignment created by the compiler, that's what I read somewhere (can't find the source, sry). I was able to recreate this behavior on some occasions by running cargo clean && cargo run multiple times and testing each time. Also changing anything in shared-crate forces to rebuild everything...

• A might be the better option in the long term, since it would not enforce a specific project setup and can be applied to both runtime OR compile time usage. This can also be put behind a feature flag for the ntex-util crate which can toggle between TypeId and CustomTypeId.

CustomTypeId has to implement same traits as TypeId and also the function pub fn of<T>() -> CustomTypeId { ... } for runtime or pub const fn of<T: ?Sized + 'static>() -> CustomTypeId { ... } for compile time use. The feature flag might look something like:

#[cfg(feature = "custom-typeid")]
type ExtType = CustomTypeId;

#[cfg(not(feature = "custom-typeid"))]
type ExtType = TypeId;

And inside extentions.rs we can simply substitute TypeId::of with ExtType::of when inserting or getting from Extensions::map.