Today’s Dirty Trick: URL Truncation

So I’m testing a Web application that sends a lot of different notification types to the users, including emails that include links to the items the user just posted on the site or things the users can do now on the site.

So instead of just clicking the link, I’m copying the link to the clipboard, and when I paste it into the address bar of the browser, I lop the last couple of characters off.

For example, if the URL in the email is:

https://(redacted)/posts/198992

I lop a bit off so it’s:

https://(redacted)/posts/1989

That should either display a post with that ID (if one exists AND the user logged in can see it) or an error message that says the post doesn’t exist.

The site should NOT spit up a Python error or an HTTP 500 error. I argue (and at length) that it should not display a generic 404 in this case, as that will make it look like there’s something wrong with your site instead of the URL it was given.

Instead of a simple problem with an invalid ID, you might find the truncated URL bollixes up some routing information (to make a long story short: Modern URLs include in the paths, separated by slashes, identifiers that tell the Web server what part of the code should handle the request). You might even want to specifically bollix the routing information to see what happens. For example, a URL like this:

https://(redacted)/users/edit/1099991/

Chop out some of the routing information:
https://(redacted)/users/edi

Where does that go? Who knows?

In any application that sends out URLs, you really have no idea how the user will handle that URL. They might click a link, they might swipe and paste, they might get a forwarded email where the URL is wrapped on two lines but the email program only makes the first part on the first line into a link the user can click. So your application has to account for and to handle elegantly URLs that are truncated.

So let it be truncated, so let it be done.

Comments are closed.


wordpress visitors