4 ms·

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

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.

thucydides 13y ago
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.
- Nanzikambe 13y ago
  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.)
  - michaelmior 13y ago
    What about someone who can't log in using a browser which is not their usual?
    - Nanzikambe 13y ago
      > 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.
  - deleted 13y ago
    [deleted]
  - prawn 13y ago
    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.
    - Kluny 13y ago
      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.
      - Morgawr 13y ago
        Or just use the site linked in the OP
  - varkson 13y ago
    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.
samdk 13y ago
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.
- adrianpike 13y ago
  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.

thucydides 13y ago

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.

Nanzikambe 13y ago
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.)
- michaelmior 13y ago
  What about someone who can't log in using a browser which is not their usual?
  - Nanzikambe 13y ago
    > 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.
- deleted 13y ago
  [deleted]
- prawn 13y ago
  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.
  - Kluny 13y ago
    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.
    - Morgawr 13y ago
      Or just use the site linked in the OP
- varkson 13y ago
  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.

samdk 13y ago

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.

adrianpike 13y ago
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.