in reply to Re^2: HTTPD-Password Self-Management and Recovery
in thread HTTPD-Password Self-Management and Recovery

I have taken a look at CGI::Application::Plugin::Authentication in the mean time and while it would be the right module to replace my previous authentication and session handling, it looks as if it is engineered only for checking the credentials, not updating them. Read-only means it's still a lot of coding to get to the management functionality I'm after.

I think that is "as expected". The .htaccess file is a static file in your webserver which must be at all times available and readable by the web-server to administer the authentication process. Many (sub-)processes/threads/workers can read the same file without any problem. But once you will write to that file, perhaps even by different (sub-)processes/threads/workers at more or less the same time, you open yourself to ugly race-conditions or unavailability of the server during the write-process.

If you are thinking of changing your set-up anyhow, why not explore a database-centered user administration?

Update: That being said, there is Apache::Htpasswd which provides write access to the .htaccess file. I have no idea how secure or safe it is and whether it implements any protection against race conditions.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

  • Comment on Re^3: HTTPD-Password Self-Management and Recovery

Replies are listed 'Best First'.
Re^4: HTTPD-Password Self-Management and Recovery
by Anonymous Monk on Dec 04, 2011 at 11:56 UTC

    Race condition is avoided by using the atomic rename operation

    Copy original-file to new-file, edit new-file, rename new-file to old-file, rename new-file .htaccess

[reply]
      That will not work.

      Consider the following:

      1. Process A wants to change the pasword file: it copies the password file to newfile-A.
      2. Process A does its edits on newfile-A
      3. Process B wants to change the pasword file: it copies the password file to newfile-B.
      4. Process A renames newfile-A to password file.
      5. Process B does its edits on newfile-B
      6. Process B renames newfile-B to password file.
      Now process A's edits are wiped out.

      Next to the atomic rename opeation, you will need file-locking too: but that means only one writer is allowed at the same time, hence unavailability of the server for all those waiting for the lock to be released.

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]

        What you are describing here is the so-called lost-update problem. This can be avoided by using file-locking as you correctly pointed out.

        File locking does not make the server unavailable (for reading the old file) as long as you only use a write-lock and not a read-lock. A write-lock is completely sufficient in this case.

        Edit: The reason I don't intend to do a database-centered login is that I would actually like not to add a database and to separate the authentication from the application.

[reply]

In Section Seekers of Perl Wisdom