While working on the Drupal 6 backport of this module and trying to make it work with drush si, I realized that Drush has trouble to generate the cookie domain value, even if you pass the URI of the site via -l. I'm incorporating TFA into an install profile, and therefore I want to set all the TFA settings using variable_get() in the install profile. Variables like tfa_enabled, tfa_fallback_plugins, and even the Twilio creds, are not a problem. However Drush is not able to generate the same value for tfa_basic_cookie_domain as my browser does.

This led me to look into how the TD cookie is used. Not setting a value for tfa_basic_cookie_domain works well (the form will not let you do that, but you can simply not set that value in the install profile, or drush vdel tfa_basic_cookie_domain after saving the form). So this begs the question, why does the user have to set a cookie domain in the form? Presumably there are scenarios where customizing this might be useful (though I'm not sure which those are) but in general it doesn't seem necessary.

I compared the cookie that gets set in both cases: 1) with the default value for tfa_basic_cookie_domain set by the browser when saving the TFA settings form, and 2) the cookie that is set when the variable tfa_basic_cookie_domain doesn't exist (this is the best I can get with drush si):
1) The default value for tfa_basic_cookie_domain that is set by my browser is something like .www.mysite.com. The cookie sent to the browser when setting a browser to be trusted is:

Domain: .www.mysite.com
Path: /

2) The tfa_basic_cookie_domain variable doesn't exist, Drupal will send a cookie an empty $domain value, and the browser will default it to the host value.

Host: www.mysite.com
Path: /

The Trust Browser feature works in both cases. Was it a conscious decision to set the cookie domain to a wider domain and include any sub-domain? Note that the Drupal cookies 'has_js', Drupal.toolbar.collapsed and _ga all are set to the Host (case #2), while the session cookie is set to apply to sub-domains (case #1). I guess the only down-side of not setting a domain cookie is that the Trusted Browser feature would not work on a sub-domain. If you make sure to redirect your users to the same domain when logging in, I believe this should be ok.

I'm going to continue using an empty value for the default domain cookie and see how far I get, but I wanted to start this conversation in case others run into the same concerns.

http://stackoverflow.com/questions/4688736/difference-between-host-and-d...

Comments

pjcdawkins’s picture

pjcdawkins commented

Your summary of the issues seems correct to me.

I think the cookie domain should not be required in the form.

banviktor’s picture

banviktor commented

Edit: I worked so much on this answer and I failed lol.

banviktor’s picture

banviktor commented

I didn't fail that bad actually.
There are 3 cases while setting the domain in setcookie().
1) Leaving it empty
2) Setting it to .domain
3) Setting it to domain

Experiment
I've set up 2 sites: example.dev and www.example.dev
www.example.dev:

echo 'www';
setcookie('c1', 'empty', 0, '/');
setcookie('c2', 'example.dev', 0, '/', 'example.dev');
setcookie('c3', '.example.dev', 0, '/', '.example.dev');
print_r($_COOKIE);

example.dev:

echo 'nowww';
print_r($_COOKIE);

Outputs:
www.example.dev:
wwwArray ( [c1] => empty [c2] => example.dev [c3] => .example.dev )

example.dev:
nowwwArray ( [c2] => example.dev [c3] => .example.dev )

The results
1) The cookie will only work on www.example.dev
2) The cookie will work both on *.example.dev and example.dev
3) Same as 2) but on some old browsers the cookie will not work on *.example.dev (see setcookie()'s domain documentation)

About the issue
Sure you can leave it empty as long as the site will only be reached from one domain only.
But for example if the site is awailable with www and without www and no redirection is done, the feature will only work properly if it's set to .example.com. Or if you'd like other subdomains to be able to use the feature it's necessary to set it up like that.
The form is perfectly okay as most of the time the default value is the one the user needs.

banviktor’s picture

banviktor commented

I forgot to include it (I had it in my failed comment), but cookie #1 won't be avaiable from *.www.example.dev either.

pjcdawkins’s picture

pjcdawkins commented

The form is perfectly okay as most of the time the default value is the one the user needs.

Yes the default is fine, but that doesn't explain why the field has to be required. An empty value works fine in many cases, as you explain, so why not let the user specify an empty value by setting the field empty?

banviktor’s picture

banviktor commented

UX-wise it wouldn't be a good solution to just remove the validation for the field since most of the users have no idea how the feature will work then. Can you suggest some kind of modification to the UI that is pretty clear on what happens when?

We could add a checkbox that disables input to the textfield and sets the cookie domain to "". The checkbox could say "Make the feature only work on this domain but none of its subdomains."

By the way were you the one who updated setcookie()'s documentation in the last couple of days? :) The domain paragraph is a lot better since.