Fiat Lux

HTTP Error 401 Unauthorized

Introduction

The Web server (running the Web site) thinks that the HTTP data stream sent by the client (e.g. your Web browser or our CheckUpDown robot) was correct, but access to the URL resource requires user authentication 1) which has not yet been provided or 2) which has been provided but failed authorization tests. This is commonly known as “HTTP Basic Authentication”. The actual authentication request expected from the client is defined in the HTTP protocol as the WWW-Authenticate header field. (Last updated: March 2012).

Generally this error message means you need to log on (enter a valid user ID and password) somewhere first. If you have just entered these and then immediately see a 401 error, it means that one or both of your user ID and password were invalid for whatever reason (entered incorrectly, user ID suspended etc.).

401 errors in the HTTP cycle

Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle:

• Obtain an IP address from the IP name of the site (the site URL without the leading ‘http://’). This lookup (conversion of IP name to IP address) is provided by domain name servers (DNSs).
• Open an IP socket connection to that IP address.
• Write an HTTP data stream through that socket.
• Receive an HTTP data stream back from the Web server in response. This data stream contains status codes whose values are determined by the HTTP protocol. Parse this data stream for status codes and other useful information.

This error occurs in the final step above when the client receives an HTTP status code it recognises as ‘401’.

Fixing 401 errors - general

Each Web Server manages user authentication in its own way. A security officer (e.g. a Web Master) at the site typically decides which users are allowed to access the URL. This person then uses Web server software to set up those users and their passwords. So if you need to access the URL (or you forgot your user ID or password), only the security officer at that site can help you. Refer any security issues direct to them.

If you think that the URL Web page *should* be accessible to all and sundry on the Internet, then a 401 message indicates a deeper problem. The first thing you can do is check your URL via a Web browser. This browser should be running on a computer to which you have never previously identified yourself in any way, and you should avoid authentication (passwords etc.) that you have used previously. Ideally all this should be done over a completely different Internet connection to any you have used before (e.g. a different ISP dial-up connection). In short, you are trying to get the same behaviour a total stranger would get if they surfed the Internet to the Web page.

If this type of browser check indicates no authority problems, then it is possible that the Web server (or surrounding systems) have been configured to disallow certain patterns of HTTP traffic. In other words, HTTP communication from a well-known Web browser is allowed, but automated communication from other systems is rejected with an 401 error code. This is unusual, but may indicate a very defensive security policy around the Web server.

Fixing 401 errors - CheckUpDown

When you set up your CheckUpDown account, you may optionally provide two items 2. Web Site User ID and 3. Web Site Password. You should provide these only if the site uses HTTP Basic Authentication. If you provide them, the CheckUpDown robot always uses them. This will result in a 401 error if in fact the site does not use this authentication. Conversely, if you do not provide them and the site does use this authentication, you also get a 401 error.

If however your URL is open to all comers, then an 401 message should not appear. Because it indicates a fundamental authority problem, we can only resolve this by negotiation with the personnel responsible for security on and around the Web site. These discussions unfortunately may take some time, but can often be amicably resolved. You can assist by endorsing our service to the security personnel. Please contact us (email preferred) if you see persistent 401 errors, so that we can agree the best way to resolve them.

Setting up Ruby and Rails

Check out our tutorial to setup Ruby 1.9.3 on OS X, Linux, or Windows

Ruby

• Ruby in 100 Minutes - Your first exposure to Ruby, focusing on the most important concepts and syntax elements.
• Encryptor - An introductory project building a rotation-based encryption/decryption program, written for middle or high school students.
• EventManager - An introduction to Ruby for new programmers doing “Extract-Translate-Load” operations against a large dataset.
• MicroBlogger - A second introductory Ruby tutorial building a rudimentary Twitter client

Rails

Blogger

An introduction to Rails by building a blog application with posts, comments, tagging, and authentication. This first Rails project basic model associations, templating, and RESTful routing.

Blogger - Advanced Topics

This is a series of extension topics from a completed blogger project. This project is a cousin of the original with a number of different implemented features to serve as a jumping off point to build proficiency with:

• Slimming Controllers
• Presenter Pattern
• Better Models With Modules

Contact Manager

A test-driven approach to developing a contact management application with people, companies, emails and phone numbers. This project uses RSpec and capybara for testing for models and entire features. This project employs tools like git and Heroku to save and deploy your work.

Merchant

A second level Rails project with more complex relationships, techniques.

Independent Work Projects

Ruby

• EventReporter - A follow-up to EventManager focusing more on Ruby object decomposition and working with Command Line Interfaces and program control flow.
• SalesEngine - This project supplies a set of CSV datafiles and challenges you to build a query/reporting API. It’s an excellent opportunity to practice TDD and manipulating collections. Also, several developers have used it as a test-bed for performance ideas like threads, distributed Ruby, and integrating with a SQL database.
• TrafficSpy - The objective is to build a HTTP traffic service like Google Analytics. Your application will allow clients to submit traffic data for that application which you will extract, store, and visualize. This project emphasizes skills in handling web requests, data management, and data visualization.
• JetFuel - The objective is to build a URL shortening service like Bit.ly. Your application will allow anonymous users and registered users to create shortened URLS. The main goal of your application is to redirect a request at the shortened URL to their long URL equivalent. Your secondary goal is to track URL usage and provide valueable statistics which you can use to share with your users and/or with advertisers.

Rails

• StoreEngine - A very challenging first Rails project, it represents 2-3 weeks work for a pair of new Rails developers. You’re challenged to build a fully functioning online store with products, categories, a cart, login/permissions, checkout, etc.
• SonOfStoreEngine - A three week project working with a “legacy” codebase adopting a version of StoreEngine that you didn’t write. You’re challenged to add new features like multi-tenency, products being in and out of stock, subdomains, and serving requests in under 100ms.
• FeedEngine - You’re probably familiar with Tumblr. In this project you’re challenged to build a service that can post text, image, and link content like Tumblr. But it also needs to hook into a user’s Twitter, Instagram, and Github accounts to pull content from those services. Oh, and you’ll need to build an API and accompanying rubygem so your background workers can run independent from the primary application.