Tell Apache not to freak out over 404, and allow Ember-CLI router/adapter logic handle slug in URL

My new Ember-CLI app uses a user portal slug in the URL to display proper information to the user. For example (fake URL): http://my.server.portals.com/robertplant

I'm using a combination of router and adapter logic to get the user portal name form the url slug, and then display the data related to it. It probably needs some more work, but here's what I have so far:

Router code extract:

Router.map(function () {
  this.route('portal', {path: '/:portal_slug'}, function () {
    this.resource('account', {path: '/'});
  });
});

Adapter code extract (for hitting the right API end point based on portal):

namespace: function () {
  var portal = window.location.pathname.match(/^\/([^\/]*).*$/)[0];
  return 'abc' + portal + '/api/v1';
}.property().volatile(),

I can hit the app locally (e.g.: http://localhost:4200/robertplant/) with no issues. It runs using Ember-CLI’s built in web server.

However, when I move the app to the server, which runs Apache, and try to hit it (e.g.: http://my.server.portals.com/robertplant), I get:

Not Found
The requested URL /robertplant was not found on this server.

Which makes sense I suppose, since there isn’t really a directory named the same as the slug. However, there has to be a way, I would think, to tell Apache to ignore the problem it thinks it is having, and allow the app router to handle it. The local web server is doing it somehow.

Ideally, the solution would leave the URL displayed the same. Also, re-writing the request to point to something like http://my.server.portals.com?slug=robertplant causes Ember-CLI assets to be looked for at the wrong path (can't set baseUrl dynamically).

I'd appreciate any feedback on how to set up the app in Apache to allow for this to happen.

Solution

Solution:

Say the current subdomain is my.portal.com. Create another subdomain that points to the same directory on the server. Name it my2.portal.com
For the first subdomain, add a mod rewrite rule which rewrites something like
```
http://my.portal.com/joe_blow
```
as
```
http://my.portal.com?portal_slug=joe_blow
```
This allows you to hit the url without a 404.
Set the asset paths (in the generated index.html) to point to the second subdomain. E.g.:
```
http://my2.portal.com/assets/app_name.js
```
This allows the app to find the assets without the issues associated with the rewrite or the slug in the url.

Of course, you can also place the assets anywhere else, including an S3 bucket. But in my case, I have a constraint of having to store them on the same server/network for security reasons. And my way you can deploy all the files to the same location.

That's it! Works like a charm.

The only thing I'm not fond of, is having to edit the index file after it's generated. I will try to automate it at some point.