Skip to content
This repository has been archived by the owner on May 10, 2019. It is now read-only.

Avoid double-counting the /sign_in page when users return from authenticating with their primary. #3971

Merged
merged 3 commits into from Oct 17, 2013
Merged

Avoid double-counting the /sign_in page when users return from authenticating with their primary. #3971

merged 3 commits into from Oct 17, 2013

Conversation

shane-tomlinson
Copy link

I am slightly uncomfortable with this and am opening to get feedback from @6a68, @kparlante and @seanmonstar.

  • Instead of using the #AUTH_RETURN hash, use ?AUTH_RETURN, which is sent to the backend and can be used to avoid double count.
  • Update tests.
  • Get rid of the testmob.org include, it has been reaped.

fixes #3970

@@ -12,6 +12,8 @@ const urlparse = require('urlparse');

// utility function to log a bunch of stuff at user entry point
module.exports = function(req, res, next) {
// NOTE - this only counts the first time the user sees the dialog, it does
// not count if the user returns from a primary.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh right, because "/sign_in" !== "/sign_in?AUTH_RETURN". Took me a moment.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should probably say that in the comment, eh?

@kparlante
Copy link
Contributor

@shane-tomlinson : its an expansion of scope, but it would be useful to count the ?AUTH_RETURN case separately. In that case, the referrer is the IdP, which would give us a window on # of unique IdPs (and a heads up if new IdPs show up).

@shane-tomlinson
Copy link
Author

@kparlante - once #3968 is merged, I'll complete this. I have most of it done, but want to use the testing from that PR to enable clean testing of parts of this PR.

@jaredhirsch
Copy link
Member

#3968 is merged, sorry I've been lagging recently 🍻

@jaredhirsch
Copy link
Member

@shane-tomlinson OK, so my concern coming in was that the querystring would be visible to other servers, and maybe get cached. Looking at our caching behavior for wsapis and the HTTP 1.1 spec, I think we should be good.

Does anything show up in the querystring that could be spoofed and cause problems? Trying to think through potential issues caused by that being visible to servers.

function entry(type, req, data) {
logger.info(type, _.extend({
browser: req.headers['user-agent'],
// IP address (this probably needs to be replaced with the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe now is the time to finally remove this slightly misleading comment?

I think we are specifically not ever logging the real IP address, it's always 127.0.0.1, is it worthwhile to bother including it?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@6a68 - on ephemeral instances, the real address is actually logged. For instance, this is what I see in router.log when running Selenium tests from Sauce:

{"browser":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0","ip":"199.27.108.155","rp":"http://logging-shane.123done.org","level":"info","message":"signin","timestamp":"2013-10-16T15:22:02.903Z"}

As you can see, I put the ip address stuff back in after seeing this. Note, we do NOT send the IP address off to kpiggybank.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that makes sense.

@shane-tomlinson
Copy link
Author

@6a68 - this should be cached in the same way as /sign_in, which is to 'allow caching, but require revalidation via ETag' - see https://github.com/shane-tomlinson/browserid/blob/99b30ac00e638398902a395296a7b0bb74cb0ad7/lib/static/views.js#L42. I must admit, that max-age=0 seems like it would disable caching.

I have removed the IP address from the logs since it was always 127.0.0.1

@@ -37,7 +37,7 @@ const MetricsKpiggybankTransport = require('./transports/metrics-kpi');
exports.logger.add(LogFileTransport, {});
exports.logger.add(StatsdTransport, {});
exports.logger.add(MetricsFileTransport, {});
exports.logger.add(MetricsKpiggybankTransport, {});
exports.logger.add(MetricsKpiggybankTransport.getInstance(), {}, true);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I use a singleton here so that I can get the same transport instance for testing.

@shane-tomlinson
Copy link
Author

This code is live on https://logging-shane.personatest.org

…ticating with their primary.

* Instead of using the #AUTH_RETURN* hash, use ?AUTH_RETURN*, which is sent to the backend and can be used to avoid double count.
* /sign_in?AUTH_RETURN logs an `idp.auth_return` message
* /sign_in?AUTH_RETURN_CANCEL logs an `idp.auth_cancel` message
* Update tests.

fixes #3970
@shane-tomlinson
Copy link
Author

I added a new commit to log new primary users, which addresses #3985

* complete_user_creation.success
* idp.auth_return
* idp.auth_cancel
* idp.create_new_user
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this list doesn't seem to include metrics.report.*

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

eh, if I'm correct, just add this in a tiny follow-on PR.

@jaredhirsch
Copy link
Member

Looks good, tests pass. R+, merging.

jaredhirsch added a commit that referenced this pull request Oct 17, 2013
…le-count

Avoid double-counting the /sign_in page when users return from authenticating with their primary.
@jaredhirsch jaredhirsch merged commit e9e9923 into mozilla:dev Oct 17, 2013
@jaredhirsch jaredhirsch deleted the issue-3970-sign_in-double-count branch October 24, 2013 16:27
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants