[WIP] Added RequestContextStore, RequestContext and SignedPrivateCookieJar

[yinho999]

Goal

Configurability

• Provide easy configuration to switch between providers (e.g., in-memory, cookies, and others)
• Use cookie store as the default for sessions, following Rails' approach

Session

• Implement a RequestContext to handle session data
• Change ctx to req in function signatures:

foo_handle(req: RequestContext) -> { .. }

Cookies Store (Cookie)

• Use both Encrypt and Signed Cookies (PrivateCookieJar) Rails
• Use app-specific cookie ID (e.g., __loco_myapp_session)

Cookies Security

• Generate app-specific secret per app, no default
• Implement SSL in production
  ​

Session Store (In Memory or Other Database)

• Provide a normal session store that looks like a hash and is permanent (e.g., session["foobar"] = 3)
• Provide options for different backends:
  • In-memory
  • Database
  • Cookie-based

Default Behavior

• Use cookie store as the default for sessions (following Rails' approach)
• Ensure this default is secure and follows best practices

Documentation and Tooling

• Provide clear documentation on configuration options and their security implications
• Consider developing tools to assist with secure configuration for production environments

Additional Considerations Rails

• Ensure proper handling of session expiration and invalidation
• Address size limitations of cookie-based storage - 4KB
• Implement proper encryption and signing of cookie data
• Consider the trade-offs between different session storage methods

Flash Messages(Optional)

• Consider implementing Flash functionality (lives only between actions) Flash

Plan

Template

[yinho999]

@jondot @schungx Here is my current development plan and the key points I've summarized from the discussion. Please don't hesitate to correct me if I've missed anything that might lead to security issues.

[jondot]

what happens to request context when there is no request involved? for example tasks, workers ?

[yinho999]

hmm, that is a good point

[jondot]

Looks like a fantastic plan!
I will keep monitoring this WIP PR

[schungx]

• Provide options for different backends:

  In-memory
  Database
  Cookie-based

I wonder if we can do something wrt cookie-based instead of just disallowing it for production. It is just the case that the hash resides on the client instead of on the server.

If the server needs to read the hash, then obviously it'll fail -- not supported.

If the server needs to write to the hash, for example to force-expire it, then it can potentially be queued up (Redis?) and replayed during the next response to be sent to the client (which will include the relevant cookie header to set the hash values).

Would this be possible?

EDIT: Come to think of it ... this may not be very useful. If I can store commands in Redis, I might as well put the session store there. Or in an in memory store.

In this case, why not just make the in-memory store the default and be done with it?

[yinho999]

• Provide options for different backends:
  In-memory
  Database
  Cookie-based

I wonder if we can do something wrt cookie-based instead of just disallowing it for production. It is just the case that the hash resides on the client instead of on the server.

If the server needs to read the hash, then obviously it'll fail -- not supported.

If the server needs to write to the hash, for example to force-expire it, then it can potentially be queued up (Redis?) and replayed during the next response to be sent to the client (which will include the relevant cookie header to set the hash values).

Would this be possible?

EDIT: Come to think of it ... this may not be very useful. If I can store commands in Redis, I might as well put the session store there. Or in an in memory store.

In this case, why not just make the in-memory store the default and be done with it?

Cookie sessions can be useful across multiple servers, the pros and cons should be around the same as arguments between JWT tokens and session tokens

[jondot]

I wonder if we can do something wrt cookie-based instead of just disallowing it for production. It is just the case that the hash resides on the client instead of on the server.

I believe if the hash is on the client and is stored on the browser, it is still being sent, and received as-is, so if the server wants, it can access the hash via incoming cookie header.

[yinho999]

@jondot Sorry for postponing this ticket. I was trying out Ruby on Rails and experimenting it to get a better idea about how the request context being used and the feels in the framework. I am going to continue this ticket this week 👍.

[jondot]

@yinho999 please note that we just pushed a request_id implementation to master (including some improvement in middleware run order), so that takes some effort off from your PR

[yinho999]

@yinho999 please note that we just pushed a request_id implementation to master (including some improvement in middleware run order), so that takes some effort off from your PR

No worries, gonna remove my current implementation right now

[yinho999]

@jondot @schungx I apologize for the long absence without notice. I will continue to work on this PR right away.