Pyramid.security questions: Double cookies? Insecure cookies? Expiration?

Question

I'm taking my first foray into the Pyramid security module. I'm using this login code to set the auth_tkt:

@view_config(route_name='LoginForm', request_method='POST', renderer='string')
class LoginForm(SimpleObject):
    def __call__(self):

        emailAddress = self.request.params.get('emailAddress')
        password = self.request.params.get('password')

        if emailAddress != 'testemail@gmail.com' or password != 'testpassword':
            errorDictionary = { 'message' : "Either the email address or password is wrong." }
            self.request.response.status = 400
            return json.dumps( errorDictionary, default=json_util.default)

        testUserGUID = '123123123'

        headers = remember(self.request, testUserGUID)
        return HTTPOk(headers=headers)

It seems to work ok, but there are some puzzling details:

First of all, 2 cookies actually get set instead of one. The 2 cookies are identical (both with name "auth_tkt") except for one difference: one has a host value of ".www.mydomain.com" while the other cookie has a host value of "www.mydomain.com" Why are 2 cookies being set instead of one? What's the significance of the difference host values?

Question 2, web tools reports that neither cookie is secure. What can I do to make sure the cookie/s are secure?

Question 3: Both cookies have an expiration value of "At end of session". What does this mean and how can I customize the expiration value myself? What's the recommended practice for login cookie expiration times?

Question 4: I don't understand why the first argument of "remember" is self.request instead of self.request.response. Shouldn't the data be remembered on the response object, not the request object?

Answer 1

1. Actually, 3 cookies are generated; one without a Domain key, one with, and a 3rd with the wildcard version of your domain (the leading dot). Your browser usually either merges the two or ignores one of those (which one differs by browser, which is why 2 are set).

   That last cookie is generated when the wild_domain option is set on the AuthTktAuthenticationPolicy (True by default); see the AuthTktAuthenticationPolicy API. You need this if your authentication cookie is to be shared between different subdomains (think app1.domain, app2.domain); your browser won't share cookies across subdomains without a wildcard cookie.

2. You need to set the secure option on your auth policy for cookies to get the secure flag set. Again, see the API.

3. No expiration is set, which means that the cookies are deleted when you close your browser (the end of the session your browser shows you). If you want your users to be logged out when they close the browser, leave this as the default.

   Only if you want sessions to last across browser closures, set a cookie maximum age, see the max_age option in the API. This option will cause browsers to store the cookie on disk to persist between browser closures, and delete them when the maximum age has passed.

   Do note that the AuthTktAuthenticationPolicy policy object can manage login sessions in a more fine-grained manner by limiting how long it'll consider any authentication cookie valid, and will let you set up a cookie refresh policy. With such a refresh policy in place users will receive new (refreshed) cookies as they continuing to use your application, but if they don't connect to your server within a set period of time, their cookie would be considered invalid and they would have to log in again.

   See the timeout and reissue_time options in the API documentation for more detail on how to configure this.

4. The policy object requires several pieces of information from the request to be able to generate the cookies, not least of all the host name of your server.