Clean Photo Album permalinks with Piwigo

I am playing for some time now with Piwigo to replace my Menalto Gallery3 online photo gallery. Key reason to look at another solution is that after the move from Gallery 2 to 3 the project (which took ages as it was a major overhaul of the code), the projects seems to have stalled.

So far I really like Piwigo as it has everything I need including iPhoto integration and a (simple) iPhone app. LDAP support is available through a plugin that is basic but suffices for my need. However, one of the key gaps for me was that it did not have any way to generate nice and simple URLs to albums that you can share easily (verbally). Although it was possible to define permalinks for an album, the URL remained ugly in my opinion.
Today I hacked a small patch together for the Piwigo 2.6 codebase that changes the URLs for photo albums to something like:

http://photo.mydomain.tld/albumname

which is exactly the way it worked for me fine (like I had with Gallery3). This only works for albums with a permalink defined, default album URL will retain the /category/<albumid> format, which is fine for my situation.

Steps to obtain more clean album URLs are:

  1. Apply this patch: piwigo-url-patch
  2. Add the following mod_rewrite rewriting rules to your Apache configuration
    RewriteRule ^/category/       /index.php/%{REQUEST_URI}               [L]
    RewriteRule ^/[^.]+$          /index.php/category/%{REQUEST_URI}      [L]

Again, in my setup this worked, I am still testing this so any feedback to improve is welcome. I did notice that occasionally the patch results in a / too many in URLs generated by piwigo, but that is silently ignored and does not affect the functionality.

To actually use the patch, define a permalink under [Administration] –> [Albums] –> [Manage] on the [Permalinks] tab.

Change Gitlab homepage using Apache’s mod_rewrite

For some time I have been looking for a way to share public projects easily using GitLab. With the Public Project option of GitLab this was already possible for some time, but it did not work quite as I would like to (i.e. I would like http://gitlab.mydomain.tld to be the URL for all public projects). Due to the way GitLab is setup, the default URL will redirect the user to the login page, which does provide a link to the Public Projects page, but was not quite what I want.

Of course, as GitLab is open source, I could change the code directly, but as I would have to do that after each upgrade of GitLab (which is monthly!) I did not want to do that. Today I found a way around changing the code by using the following mod_rewrite rules to my Apache configuration (I placed this in the <VirtualHost> configuration but should also work from a .htaccess file):

# Redirect /users/sign_in to /public unless it has a local refferer
# This makes the public projects page the homepage instead of the login page
RewriteCond   %{HTTP_HOST}@@%{HTTP_REFERER}    !^([^@]*)@@https?://1/
RewriteRule   ^/users/sign_in$                 https://%{SERVER_NAME}/public/          [R,L]

This is inspired by a blog post on referer checking from the Apache .htaccess file. To get to this solution I just had to realize that an internal redirect by the application clears the referrer and apply the opposite logic to intervene when this happened (no referrer implies a redirect, when the user clicks on a link the request will have a referrer). How this works is:

  1. The user visits http://gitlab.mydomain.tld/
  2. GitLab redirects this request to its sign_in page
  3. The browser requests the sign_in page, as this was a redirected page the referrer will be empty
  4. The above mod_rewrite rule kicks in and redirects the user to the public projects page

For me this setup works as I expect. The only caveats are that users with browsers setup not to provide a referrer (e.g. for privacy reasons) may no longer be able to login and that a direct link to the sign_in page won’t work (the user will be redirected to the public projects page and has to click the sign_in button). For my setup both are no issue, let me know through the comments if there are other issues or perhaps solutions for this.

Login issues after upgrade to GitLab 6.5

I have been playing around with Gitlab, the open-source self-hosted Github clone for a while now. I plan to use it to publish the scripts and small programs I did over the last few years and will still create later this year.

After the upgrade to Gitlab version 6.5.1 (which was a breeze BTW thanks to their excellent upgrade script) I noticed I could no longer login. to the server. In the logfile log/production I found messages like:

Started POST "/users/sign_in" for 2001:XXX:XXXX:X:XXX:XXXX:XXXX:XXXX at 2014-02-02 13:53:46 +0100
Processing by Devise::SessionsController#create as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"XXXXXXXXXXXXXXXXX", "user"=>{"login"=>"XXXXXXX", "password"=>"[FILTERED]", "remember_me"=>"0"}}
Can't verify CSRF token authenticity
Redirected to https://gitlab.mydomain.tld/
Completed 302 Found in 123ms (ActiveRecord: 7.3ms)
Started GET "/" for 2001:XXX:XXXX:X:XXX:XXXX:XXXX:XXXX at 2014-02-02 13:53:46 +0100
Processing by DashboardController#show as HTML
Completed 401 Unauthorized in 1ms
Started GET "/users/sign_in" for 2001:XXX:XXXX:X:XXX:XXXX:XXXX:XXXX at 2014-02-02 13:53:46 +0100

 
This turned out to be a known issue with the installation of Gitlab. Since Gitlab is only supports NGinX while I am running it on Apache, I needed to dig a bit further for the solution. The problem was caused by a security enhancement in Gitlab 6.5 in combination with HTTPS. Since the SSL processing is handled by Apache, which uses mod_proxy to connect to GitLab only using HTTP, cookies no longer worked properly. The solution was pretty simple, it required the following statement to be added to the Apache Virtual Host configuration:

RequestHeader set X_FORWARDED_PROTO 'https'

Please note that this does require mod_headers to be enabled, if this is not enabled, issue to following two commands to enable it:

sudo a2enmod headers
sudo /etc/init.d/apache2 restart