Renaming app directory to 1234 breaks Auth

[mehlah]

Howdy folks,

I'm opening a ticket while digging deeper, 'cause maybe someone will have a clue faster.

The problem, as I see it

Taken a fresh app and directories layout, and renaming the main app/ directory to 1234 (or any integer), break Auth.

Environment details

I'm using PHP 5.3.6, nginx, and all tests are green

Background

I'm deploying an app using Capistrano and a home made gem for Lithium easy deployments.
Capistrano, by default, creates a directory layout as follows:

[deploy_to]
[deploy_to]/releases
[deploy_to]/releases/20080819001122
[deploy_to]/releases/...
[deploy_to]/shared
[deploy_to]/shared/log
[deploy_to]/shared/pids
[deploy_to]/shared/system
[deploy_to]/current -> [deploy_to]/releases/20100819001122

Each time you deploy, a new directory will be created under the “releases” directory, and the new version placed there. Then, the “current” symbolic link will be updated to point to that directory. (For now, don’t worry about the shared directory; we’ll get to that eventually.)

The web server's document root should be set to the [deploy_to]/current directory.

That means, the app/ directory name is a timestamp, which break things right now.

A "maybe" related ticket: http://dev.lithify.me/lithium/tickets/view/367

[mariuswilms]

This todo might be the cause for the problem you are seeing. https://github.com/UnionOfRAD/lithium/blob/master/action/Request.php#L592 Can you verify this, manually by changing those values and/or providing a test case against the session auth adapter?

[gwoo]

set session.name in Session::config()

[nateabele]

@gwoo: Should Session throw an exception if that happens?

[gwoo]

Probably better to change the behavior so it uses a static string like 'lithium-app'.