You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a low priority feature request, since the use of cookies doesn't functionally affect Blueprint currently.
A typical pattern used by HTTP servers is to store a session ID / user ID for a logged in user in a cookie. The golang HTTP server API has the ability to easily do this.
However, in the workflow spec, there is nothing saying that a frontend server is going to be deployed over HTTP (by design). So, any API that wants a session ID / user ID should explicitly pass these as function arguments.
If we want to support using session IDs in cookies, then probably the best way to do it is in the HTTP plugin. When a wiring spec configures an HTTP server, it could optionally specify which func arguments should come from cookies vs. as actual arguments; likewise it could do the same with return values.
The text was updated successfully, but these errors were encountered:
This is a low priority feature request, since the use of cookies doesn't functionally affect Blueprint currently.
A typical pattern used by HTTP servers is to store a session ID / user ID for a logged in user in a cookie. The golang HTTP server API has the ability to easily do this.
However, in the workflow spec, there is nothing saying that a frontend server is going to be deployed over HTTP (by design). So, any API that wants a session ID / user ID should explicitly pass these as function arguments.
If we want to support using session IDs in cookies, then probably the best way to do it is in the HTTP plugin. When a wiring spec configures an HTTP server, it could optionally specify which func arguments should come from cookies vs. as actual arguments; likewise it could do the same with return values.
The text was updated successfully, but these errors were encountered: