How to efficiently store a DBIx::Class object in session ?

[fluca1978]

I don't know if this is possible at all, I suspect it is not, but I'm asking to be sure.
In my application I have the logged in user that is represented by a tuple in a database, hence I use DBIx::Class to represent it.
I've created an helper method, named current_user that looks up everytime it is called, if the user is logged in.
The idea is to store in the session the username and perform a query against the database for the username to retrieve the user object:

    $self->helper( current_user => sub {
		       my ( $self, $username ) = @_;
		       $username //= $self->session->{ username };
		       $self->log->debug( "Username found in session: $username" );
		       return undef unless ( $username );

		       my $db = MyApp::Schema->connect_database( $self->config->{ database }->{ production } );
		       my $user = $db->resultset( 'Person' )->find( { username => $username } );

		       $self->session->{ username } = $user ? $user->username : undef;
		       return $user;

		   } );

Is there a way to store directly the DBIx::Class user object as I can do within the stash, in the session? Or is this the only available solution to get information about the logged in user?

[ajmetz]

I'm learning and others likely know best/better, so more asking questions to provoke thought: I don't know if the query might become outdated if stuff in the database changes during a session, and otherwise you could simply run this once when authentication is successful, and then stash the user object in the stash? Is it possible to directly write a ResultSet that takes/expects a username param, and then just call that from the database object, after setting up a db plugin that becomes your glue between mojolicious and dbix class? Hm.

There's a very basic example here,
where a user is returned as a new user object, in a dedicated Users package:
https://metacpan.org/release/SRI/Mojolicious-9.36/source/examples/login/lib
Of course it's super basic - usernames and passwords are plain text in the code.

This other example app uses Mojo::Pg instead of DBIX::Class and is also super simple - a blog app with only posts, and no actual users. Ah well. I found it useful for how they setup a database helper. I've heard users of DBIx::Class do something similar to provide a thin layer of "glue" between Mojolicious and DBIx::Class, and beyond that I'd have to defer you to others that do this more often - yourself included. You've obviously been using both together yourself, whereas I've only used Mojo::SQLite
https://github.com/mojolicious/mojo-pg/tree/main/examples/blog/lib

[ajmetz]

Oh - your profile says you're Perl and PostgreSQL passionate. You probably know Mojo::Pg and all that already, ^_^. I'd be curious to learn more about DBIx::Class with Mojolicious, if you've tips in that regard.

[rabbiveesh]

I wouldn't recommend trying to store an object in the session for a few reasons:

1. the session cookie is signed, not encrypted, so you may end up bleeding data that you didn't want to
2. you can't actually do what you want to - you'd have to serialize the object to json via a TO_JSON method, which you'd still have to make back into a proper object on your side
3. data may get stale - this isn't really an issue for the stash, b/c that's a perl value that only exists for your req/res cycle (which, to be fair, could still get stale, but you can handle that better), whereas the cookie may last until it expires (a week, a month?)

What you have there is the best option, just store a PK in the session + pull it in during an under that guards your needs-auth routes

[fluca1978]

I'd be curious to learn more about DBIx::Class with Mojolicious, if you've tips in that regard.

I don't have any tips, that's why I was asking. So far I've created only an helper method current_user and a method in the schema that connects to the database depending on app configuration, nothing more.

[fluca1978]

What you have there is the best option, just store a PK in the session + pull it in during an under that guards your needs-auth routes

Ok thanks, at least I guessed the right approach!