up arrow HTTP Authentication

Some of you seem to confuse Basic authentication with form-based authentication. They’re not the same and the differences are important. If you don’t configure siege for the appropriate authentication method, it will be on the outside looking in at an HTTP-401.

Basic authentication occurs at the protocol level. It was originally described in HTTP/1.0 and later moved to RFC 2617. Basic authentication is a challenge/response framework. When the server receives a request for a protected resource, it challenges the user to authenticate himself. It will make the item available only after the user is autheticated.

Here’s an example exchange using basic.php from the html directory inside the siege source code:

GET /siege/basic.php HTTP/1.0
Host: http://www.joedog.org
Accept: */*
Accept-Encoding: gzip
User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.71b6)
Connection: close
HTTP/1.1 401 Authorization Required
Date: Thu, 16 Feb 2012 13:09:53 GMT
Server: CERN/1.0A
X-Powered-By: PHP/5.2.5
WWW-Authenticate: Basic realm="siege_basic_auth"
Status: 401 Unauthorized
Content-Length: 178
Connection: close
Content-Type: text/html; charset=WINDOWS-1251
GET /siege/basic.php HTTP/1.0
Host: http://www.joedog.org
Authorization: Basic c2llZ2U6aGFoYQ==
Accept: */*
Accept-Encoding: gzip
User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.71b6)
Connection: close
HTTP/1.1 200 OK
Date: Thu, 16 Feb 2012 13:09:53 GMT
Server: CERN/1.0A
X-Powered-By: PHP/5.2.5
Content-Length: 278
Connection: close
Content-Type: text/html; charset=WINDOWS-1251

See what happened? Siege requested /siege/basic.php and the server was all “Whoa! I don’t know who you are.” It issued an HTTP 401 challenge to siege which responded by sending its username and password in BASE64 encryption: c2llZ2U6aGFoYQ==

In this example, I emulated HTTP Basic authentication with a php program. Typically, Basic auth is setup at the server level. Here’s an example in apache:

<Location "/siege">
   AuthType basic
   AuthName "siege_basic_auth"
   AuthBasicProvider file
   AuthUserFile /var/www/etc/passwd
   AuthGroupFile /var/www/etc/group
   Require valid-user
   Require group siege
   Satisfy All
 </Location>

To configure siege to use basic authetication, you need to add a login to your .siegerc file. Search the file for WWW-Authenticate. The directive is login and it takes three values separated by a colon. username:password:realm. Our basic.php username and password are ‘siege’ and ‘haha’. So our login looks like this:

login = siege:haha:siege_basic_auth

The third argument (realm) is optional. If you don’t specify a realm, siege will send ‘siege:haha’ every time it faces an HTTP basic challenge. By setting a realm, you can configure it to use multiple logins:

login = admin:secret:Administration
login = siege:haha:siege_basic_auth
login = root:d41ly:high_level

Now you can also restrict access programmatically. This is referred to as form-based authentication. In order to configure siege to login in this manner, you’ll need to reproduce a browser’s action.

To illustrate this, we’ve included login.php in the html directory of the siege source code. That page accepts both GET and POST requests. It produced an HTML form that looks like this:

<td>Username: </td><td>
<input type='text' name='username' value='' size='30'></td>
<td>Password: </td><td>
<input type='password' name='password' value='' size='30'></td>

To login to this form, you’ll need to provide field values that match the form. Your parameters must match the form input names. In this case it’s ‘username’ and ‘password’.

http://my.server.com/login.php?username=siege&password=haha
http://my.server.com/login.php POST username=siege&password=haha

If your entire site requires authentication you can add a login URL to your .siegerc file. If this value is set, siege will access that URL before it does anything. Search your .siegerc file for ‘login-url’. Here’s an example using one of the URLs we constructed above:

login-url = http://my.server.com/login.php POST username=siege&password=haha

After it hits that URL, siege will start running through the list of URLs you created.

Happy hacking.

Posted in Applications, Siege | 8 Comments

8 Responses to “HTTP Authentication”

  1. Nelson says:

    Hi,
    Siege is awesome! One question on mutliple login-url’s. I have entered three login url’s in .siegrc, one on each line as instructed:

    login-url = https://myapp.com/sessions/create?email=[email protected]&password=testpw
    login-url = https://myapp.com/sessions/create?email=[email protected]&password=testpw
    login-url = https://myapp.com/sessions/create?email=[email protected]&password=testpw

    then I run
    siege -c 3

    it will fire up 3 clients, but it will only use the first login-url specified, ignoring the second two I entered. Any ideas what I may be doing wrong?
    Thanks in advance!

    • Jeff Fulmer says:

      You’re doing nothing wrong. siege only support one login url. If you use the latest version with –reps=once and you put all of your login urls at the beginning of your urls.txt files, each client will pick up its own login.

      • Nelson says:

        Wow, thanks for the rapid reply. I added the url’s to the urls.txt file (and removed them from the .siegrc file), and run siege as such:

        siege -c 3 -reps=once

        but with the -reps=once option, it runs 0 transactions :( Now I am really confused.

        • Nelson says:

          Wow, thanks for the rapid reply. I added the url’s to the urls.txt file (and removed them from the .siegrc file), and run siege as such:

          siege -c 3 -reps=once

          but with the -reps=once option, it runs 0 transactions :( Now I am really confused.

          Ah, I’m using 3.05, I noticed there is now a 3.06-beta I guess I should be using. I’m not sure the -reps=once is really what I wanted – I am using siege to load test while deploying code and wanted it to continue running, the only way to do that now would be to add a whole lot of urls so that it doesn’t run out.

      • Nelson says:

        Using the -reps=once, or -reps=1 flag, results in 0 transactions being processed and siege exits. I’m on OSX.

        $ siege -c 3 -reps=once -f /usr/local/etc/urls.txt
        * SIEGE 3.0.6-beta2
        ** Preparing 3 concurrent users for battle.
        The server is now under siege…
        done.

        Transactions: 0 hits

        If I run it without the -reps flag, it runs as expected though.

        I’m also confused by this statement in the .siegrc file, it seems to be in conflict with your comment response:
        # Siege versions after 2.69 support multi logins; you can configure
        # them with multiple login-url directives.

        Is there a source code repository out there for siege? I wouldn’t mind helping to update the docs.

  2. Alex says:

    So i added both login and username/password settings (tried with both and separetely to my siegerc file).
    Still if i execute siege, i only get 401 responses.
    I know the username and password are correct and the website is hosted on IIS.

Leave a Reply




Recent Comments

  • Mirko: Wow! This trick saved my day :) thanks a lot
  • The Spaniard: greatest team ever
  • Mike Smith: I find that Dunning-Kruger explains a lot. The difficult part is getting help to those that suffer from...
  • Sohan: I am using node-js http server. I created http request to hit the server and log the message. In that case...
  • Jeff Fulmer: I don’t know what “simple http server” means. If you’re using apache out of the...