Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID

Saasy Configuration help

edited April 2013 in Apps


It looks like saasy uses subdomains for each customer, so I don't think saasy supports this out-of-the-box, but this is the way we'd like to configure our URLs (we're basically following github here):

"/" -- landing page, different view for customers and guests.
    -- reserved URLs for things like 'admin' and 'login'
    -- unique login name chosen at registration; dashboard view; can be organization or individual.
    -- customer-unique project name chosen when project created.
    -- reserved URLs for customer-specific properties and actions, like 'profile' or 'projects'.
    -- reserved URLs for project-specific properties and actions, like 'profile' or 'resources'.`

The site is multilingual and interface language selection will be by cookie, set by selecting a language in the interface, defaulting to the browser setting. So the URLs won't need to be modified. The content can be in a different language from the interface and the content language will be set by query string: ?lang=de

The API would be served from a secured 'API' subdomain, using HMAC authentication.

Last but not least, we have our development environments setup as subdomains:,

So... I have saasy installed and used it to build a skeleton app at apps/omr. Just some pointers to get me going from here would be helpful.



  • We set it up in Saasy to use subdomains following the Basecamp model (work project needed this), but it could be made to work both ways as a setting. URLs are easier to manipulate and setup than wildcard subdomains too, so that could provide a good default too.

    The file that manages most of that is lib/App.php in the Saasy app. The bootstrap() method determines the customer ID from the subdomain, so that would need to to check for the setting and switch behaviour. There are a few other methods there too like base_domain() and make_href() that will need to be aware of the setting.

    The account redirect and subdomain editing would also have to change in handlers/account.php so that they're modifying their username instead essentially. But the schema should work without change.

    If you look at App::href(), it's using the app_alias setting from the app config. That setting would probably just go away in this case.

    Also take a look at the apps/navigation/handlers/cookie.php handler. That's meant to help with switching languages when the negotiation method uses cookies.

  • Thanks for the quick reply! I'll see what I can do. :-)

Sign In or Register to comment.