Summersault
Home About Us Services Portfolio Community Support
Database Driven Websites
community home
local community
partner community
online community
weblog


Archives: Categories: Authors:

 

Summersault Weblog

Access in URLs considered harmful

Posted by Mark Stosberg on February 4th, 2006

I’d like to expand on one of the points in Tim Berners-Lee excellent recommendations on designing a good URL. He suggests leaving access out of the URL. An example of that would be the inclusion of “Public” in this bug tracking URL.

Tim is concerned about this primarily because URL access changes over time, causing the URL to need to change when the resource hasn’t changed.

There’s a bigger problem with putting access in URLs. In the era of web2.0, more sites are data-driven, providing different views of the same resource depending on how you access it. Commonly, an administrator may see links to edit and modify the data, while the public has fewer or no options to alter the content.

The problem comes when people try to share URLs to resource between different access groups. Instead of displaying the resource, the user may be prompted to login, since they are a different group than the one needed to view the resource. That’s somewhat silly– why block me from accessing a resource that I can see, even if it’s a bit different than what the sender sees?

Imagine if a free news site like Slashdot used different URLs for the paid subscribers– They won’t be able to copy/paste working article URLs to friends without accounts!

The bug tracking system mentioned above as a problem like this. If someone sent me the bug tracking link above, I would see the less useful public view of the resource, instead of having it displayed in the software developer’s view, which I should have access to do.

Alternative solutions are specific to the application framework being used, and can be about as easy to implement– the mapping of rights to resources is simply provided somewhere else besides the URL.

Some people like for URLs to provide a link to a precise state of a website, and it’s true that showing different versions to different people depending on their authentication changes that. We’ll see more of this as web pages evolve from unchanging resources into interactive applications. As with desktop applications, the only way to recreate a particular state of the application is with a particular sequence of mouse movements and clicks, or keyboard shortcuts.

These applications remain valuable despite every state not having a direct URL reference. On the web, however, people have come to expect and appreciate consistent results and when using “Back” and “Forward” to navigate through history. This metaphor doesn’t translate perfectly when a URL represents a dynamic application.

I don’t see consensus about best addressing this as we move to richer internet experiences, but I look forward to the conversation!


Did you find this entry interesting or useful? Please tell us about it!

One Response to “Access in URLs considered harmful”

  1. Michael Peters Says:

    I think you raised some interesting points. If the URL represents a resource then yes, I think access control built into the URL can be frustrating when that URL is shared. However, if the URL represents an application (not a static resource) then there is not guarantee that what you see is even shareable.

    I think a good transitional approach (as normal users change their web-experience from a “page-view” to an “application-view”) is something like what google maps does. You can’t just copy paste the URL to a friend and expect them to see the same map you’re seeing. But you can press a nifty little button/link to create a URL to a “static” shareable resource.

    Also, since AJAX apps still use URLs in the background (although hidden from the user) I see no problem in placing access control in those URLs.

Leave a Reply

The opinions expressed by individuals posting in the Summersault Weblog are not necessarily those of Summersault, LLC. While we try to insure the quality and accuracy of the information presented here, we make no guarantees about its suitability for any particular purpose.