expose the encoding option

[AndreasChristianson]

Currently hapi-auth-cookie uses Iron when encrypting. When using server side sessions the cookie may only be a random hash. In this case encrypting the cookie via Iron is unneeded. I'd prefer to pass in the cookie encoding (https://hapijs.com/api#-serverstatename-options) and have the cookie not be encoded.

below is an example. The login route sets no information in the cookie.
server registration:

      ...
        await server.register(hapiAuthCookie);

        const cache = server.cache({
            segment: 'sessions',
            expiresIn: config.get('server.auth.sessionTimeout')
        });

        server.expose('sessionCache', cache);

        server.auth.strategy('session', 'cookie', {
            cookie: config.get('server.auth.cookieName'),
            password: config.get('server.auth.cookiePassword'),
            encoding: 'none', // **This is an option I wish I had**
            isSecure: config.get('server.auth.useSecureCookies'),
            validateFunc: authenticate
        });

        server.auth.default('session');
      ...

login handler:

async (request, h) => {
    const {username, password} = request.payload;

    const user = await request.server.methods.getUser(username);
    const isValid = await validatePassword(user, password);

    if (!isValid) {
        const message = 'Invalid username or password.';

        return h.response({message}).code(403);
    }

    const credentials = {
        user: {
            id: user.id,
            name: user.name
        },
        scope: user.scope
    };
    const sid = crypto.randomBytes(8).toString('hex');

    await request.server.plugins.auth.sessionCache.set(sid, credentials, 0);

    request.cookieAuth.set(sid); // **I want to pass sid as a string. It need not be encoded**
    const message = 'Successfully logged in.';

    return h.response({
        ...credentials,
        message
    });
}

[Marsup]

You probably used search and saw #100, so my only question is: why ? :)
Note that I'm not the maintainer of that module and opinions may change, but I doubt it.

[AndreasChristianson]

I did not search thoroughly. My fault.
That issue is from three years ago, perhaps the discussion could be reignited.

[mrlannigan]

I would echo Marsup's question of why? What use case would make this feature necessary?

[AndreasChristianson]

@mrlannigan,

See my example above where user information is stored in a cache on the server side and keyed to a random string in the auth cookie. In this case no information is being stored in the cookie, it is just a random string. Thus encrypting the contents incurs both cpu and network overhead.

I don't think it is strictly necessary, but it would be convenient.

[Marsup]

So if I manage to guess your random string because it's not so random or not so hard to collide with an existing one, I get access to someone else's account? It has potential to be a footgun, I'd also rather not support it.

[AndreasChristianson]

Sure if your session id is const sid = ++lastId; or something equally terrible this presents quite the security hole.

However, shouldn't users have the option to make that mistake? Refusing to allow this option goes further than "secure by default"; instead it feels like "potentially insecure options not supported".

[hueniverse]

I don't want to expose that. The cookie encoding is part of the overall security architecture of this module. If you need something else, it's small enough to fork.

[lock]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.