Ideally, the _GG_SESSION cookie would have its max-age updated after every successful request. This would make sure a user would never have to log back in as long as they were using the upstream application regularly.
Unfortunately, the library we are using to proxy http requests (http-reverse-proxy) doesn't provide any easy way to modify a response.
Right now, the datatype defining how to handle a request is defined like the following:
data WaiProxyResponse = WPRResponse WAI.Response
-- ^ Respond with the given WAI Response.
--
-- Since 0.2.0
| WPRProxyDest ProxyDest
-- ^ Send to the given destination.
--
-- Since 0.2.0
| WPRProxyDestSecure ProxyDest
-- ^ Send to the given destination via HTTPS.
| WPRModifiedRequest WAI.Request ProxyDest
-- ^ Send to the given destination, but use the given
-- modified Request for computing the reverse-proxied
-- request. This can be useful for reverse proxying to
-- a different path than the one specified. By the
-- user.
--
-- Since 0.2.0
| WPRModifiedRequestSecure WAI.Request ProxyDest
-- ^ Same as WPRModifiedRequest but send to the
-- given destination via HTTPS.
| WPRApplication WAI.Application
-- ^ Respond with the given WAI Application.
Ideally, this would be changed so that WPRModifiedRequest also took a function for changing the response:
This issue will require updating the http-reverse-proxy library, so it might take longer than the other issues. This issue should probably be addresses before the other issues in the same milestone.
Ideally, the
_GG_SESSION
cookie would have itsmax-age
updated after every successful request. This would make sure a user would never have to log back in as long as they were using the upstream application regularly.Unfortunately, the library we are using to proxy http requests (
http-reverse-proxy
) doesn't provide any easy way to modify a response.Right now, the datatype defining how to handle a request is defined like the following:
Ideally, this would be changed so that
WPRModifiedRequest
also took a function for changing the response: