Hacker News Reader

Comment by Nanzikambe | Hacker News Reader

I realise this is to assist with support, but why would anyone other than the owner of this site use it when they could just pull the user agent from their own logs when/if there's a need?

Every webapp I've ever written logs user agent in the audit trail because that's often useful both in support and detecting unwanted stuff. I'd have to assume that's a fairly common practise.

Barring an obvious use case I'm missing, it feels like a poorly written version of www.mybrowserinfo.com dressed up the theme de jour, minus the detail.

View on HN

When I'm talking to my clients, it's so much easier to tell them to use to a site like this.

Them: "When I click the button, the menu shows up. But it disappears as soon as I hover over it.

Me: "What browser do you have?"

Them: "Google, I think."

Me: "Let's make sure. Could you go to whatbrowser.org and tell me what it says?"

Much simpler than having to fish through logs.

Them: "When I click the button, the menu shows up. But it disappears as soon as I hover over it"

Me: What's your username?

Them: jdoe@somehost.com

  $ mysql -e "SELECT useragent FROM login_audit WHERE user = 'jdoe@somehost.com'"
  +---------------------------------------------------+
  | useragent                                         |
  +---------------------------------------------------+
  | Mozilla/1.22 (compatible; MSIE 2.0; Windows 3.1)  |
  +---------------------------------------------------+

Me: thumping noises on wood

Them: Yes?

  $ mysql -e "DELETE FROM users WHERE user = 'jdoe@somehost.com'"

Me: Problem resolved, goodbye.

(Admittedly this is probably why they don't let me do support, but the point remains, it's trivial and you should have this info.)

And for someone doing basic support who doesn't or shouldn't have access to the database? These sites make that sort of thing easy.

A great job to give an intern is to get them to write a nice front-end for support techs to use. Then get a manager in training to audit the code.

Or just use the site linked in the OP

Writing SQL over the phone? That sounds like a massive pain. Especially one handed, I don't get a fancy headset. Thinking on the phone is hard enough.

In my own case the clients have multiple users using one account so you can never be sure who's user agent in the logs corresponds to what.

What about someone who can't log in using a browser which is not their usual?

> What about someone who can't log in using a browser which is not their usual?

You're assuming a couple things about our hypothetical login_audit table, neither of which are neccesarily true and both of which would make our audit table functionally as useless (at least to me) as the OP's site

  * That we only store the last useragent
  * Only successful logins are recorded

In the latter case, I probably needn't (but I will) point out that failure to make any entry in the table would imply more serious connectivity issues being afoot.

If your app gets a nontrivial number of visitors this is probably way easier than trying to pull a specific user's request out of logs.

And once you reach a certain size the person doing user-level support very likely doesn't have access to server logs.

I'd argue as your visitors scale, so should the ability to trace individual requests, and as your user-level support team scales, so do the tools you use to support them.

Another nice benefit is that building out a quick internal tool can be a great afternoon hack to clear your mind. It doesn't have to be good, just something to remove some pain.

We're tagging pretty much every request & correlating it with a user, and are able to pull logs pretty quickly. It's not hands-off, but we've built tooling to make it pretty straightforward to dig whats up.

Reply on news.ycombinator.com