• 1 Post
  • 36 Comments
Joined 1 year ago
cake
Cake day: July 15th, 2023

help-circle


  • That’s correct, it is just plain text and it can easily be spoofed. You should never perform an auth check of any kind with the user agent.

    In the above examples, it wouldn’t really matter if someone spoofed the header as there generally isn’t a benefit to the malicious agent.

    Where some sites get into trouble though is if they have an implicit auth check using user agents. An example could be a paywalled recipe site. They want the recipe to be indexed by Google. If I spoof my user agent to be Googlebot, I’ll get to view the recipe content they want indexed, bypassing the paywall.

    But, an example of a more reasonable use for checking user agent strings for bots might be regional redirects. If a new user comes to my site, maybe I want to redirect to a localized version at a different URL based on their country. However, I probably don’t want to do that if the agent is a bot, since the bot might be indexing a given URL from anywhere. If someone spoofed their user agent and they aren’t redirected, no big deal.


  • User agents are useful for checking if the request was made by a (legitimate self-identifying) bot, such as Googlebot.

    It could also be used in some specific scenarios where you control the client and want to easily identify your client traffic in request logs.

    Or maybe you offer a download on your site and you want to reorder your list to highlight the most likely correct binary for the platform in the user agent.

    There are plenty of reasonable uses for user agent that have nothing to do with feature detection.


  • JSON Problem Details

    https://datatracker.ietf.org/doc/html/rfc9457

    • It has a specification, so a consumer of the API can immediately know what to expect.
    • It has a content type, so a client sdk can intelligently handle the response.
    • It supports commonly needed members which are a superset of all of the above JSON examples, including type for code and repeating the http status code in the body if desired.
    • It is extensible if needed.
    • It has been defined since at least 2016.

    This specification’s aim is to define common error formats for applications that need one so that they aren’t required to define their own …

    So why aren’t you using problem details?













  • Really interesting! I wonder what would happen if you combine these two properties. Suppose some length of the middle is all walls, and the hooks are infill, or vice versa. Is there an optimal mix that maximizes the weight it can support in your testing, or have you found the optimal configuration (with infill along the entire length) already?


  • I recently went through these exact pains trying to contribute to a project that exclusively ran through Discord and eventually had to give up when it was clear they would never enable issues in their GitHub repos for “reasons.”

    It was impossible to discover the history behind anything. Even current information was lost within days, having to rehash aspects that were already investigated and decided upon.