Small issue with AJAX, XMLHttpRequest and CORS

[d1a8lo24]

If you installed the forum in the root or in a folder and access your site either via http://example.com or http://example.com/flarum without the "www" or subdomain

You might have encounter a small problem when clicking to a discussion in this case no content was loaded.

Using firebug or your developer's browser tools there is an error that pops up on your javascript debugging console, in this case you may see something like this.

XMLHttpRequest cannot load http://www.example.com/api/discussions/1?page%5Bnear%5D=0. Invalid HTTP status code 500

or

Resource from origin 'http://www.example.com' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://example.com' is therefore not allowed access.

This happens because when Flarum starts an ajax call to the API it does it by using the "www" in the URL so if your site is http://example.com and you click on a discussion it will call the API via ajax to http://www.example.com/api/discussions/ which it is not allowed since its a security issue in this case is because they are not the same domain.

Anyway I think just a small edit somewhere where the URL writing is should fix this so will leave it to the experts at Flarum.

But at the moment what you can do is use the htaccess file to rewrite how people access your site in this case by adding the www.

In my case I am using Apache 2.2 so I added the following code to my htaccess file.

<IfModule mod_rewrite.c>
  RewriteEngine On
  # Rewrite "domain.com -> www.domain.com"
 RewriteCond %{HTTP_HOST} !^www\..+$ [NC]
 RewriteCond %{HTTP_HOST} (.+)$ [NC]
 RewriteRule ^(.*)$ http://www.%1/$1 [R=301,L]

</IfModule>

[franzliedke]

I would say this is up to the website owner, not to Flarum.

Other thoughts, anyone?

[luceos]

We need to document this as faq. I agree this is a server administrator topic, installing with www and loading without or vice versa.

[tobyzerner]

We could consider doing a check in Flarum to see if the request domain is the same as the configured domain, and redirecting if not. Is something like this a standard practice in web apps?

[d1a8lo24]

Well its been a while since I reported this. It shouldn't be that difficult, it just seems that somewhere in the code the www is hard coded, at least thats what I am guessing.

And remember this is not on the owner/administrator etc... side. this is part of the application because the call is being made when accessing the application not the server and is the application that is adding the www, that is why I mention that is hard coded somewhere.

Is just like when you're coding HTML and trying to make all your links work with out hard coding the domain.

Linkage examples:

The first link will get the css file that resides in the root directory using the www sub domain and its hard coded to make sure its pointing to the root directory.

The second link is pointing to a css file but it will always point to a css file on the directory you're browsing not the root directory and it will automatically know if you're accessing the site via www or just the main domain. This ensures compatibility accessing the files through the right domain but wrong directory. This link will point to "http://www.sample.com/file.css", "http://www.sample.com/section/file.css", "http://www.sample.com/section2/file.css" etc... depending on where you're on the site, so if you only have 1 css file and its on the root folder then you will have a lot of trouble when you're on section2 of your site since that file will not be available link it the second way.

Now the third line does the same thing that the second line but it will always access the file using the root directory and the correct domain.

<a href="http://www.sample.com/file.css" />
<a href="./file.css" />
<a href="/file.css" />

So I really haven't checked where the API url is coded to see how is it resolving the domain.

But anywhere you're doing that API AJAX call thats where we should look at the URL and how is it resolving the domain and thats where I think the www is hard coded.

I am just guessing here but like jquery really easy URL that will call from the main domain that the application is being access through whether is being access through www or just the main domain.

$.ajax({
     type: "GET",
     url: "/api/discussions/"
 });

Anyway I haven't updated my forum so I am going to updated and check out if the problem still there and to see if I can find the fix. Again it shouldn't be that hard to resolve.

[tobyzerner]

The base URL is defined (I guess you could say "hardcoded") in config.php. That's used as the base when making requests to the API. This is done so that you could potentially hook up a Flarum client instance with an external API on another domain/server.

[luceos]

redirecting in the code to the configured base url will break any (future) multi tenant extensions

[tobyzerner]

but wouldn't you have a different base URL configured for each tenant?

[luceos]

Flarum.today now has specific configs (tenant-1.config.php, tenant-2.config.php ..) loaded based on the requested hostname. A better approach would be some middleware (as Laravel calls it) to set the url dynamically based on the hostname. As long as that will remain possible, there is no objection against redirecting to the configured URL.

[franzliedke]

We could consider doing a check in Flarum to see if the request domain is the same as the configured domain, and redirecting if not. Is something like this a standard practice in web apps?

Nope, I'd say it's up to the server, not the app.

[luceos]

I think I agree more with @franzliedke at this point. But it requires documentation.

[tobyzerner]

OK.

[sijad]

implement OPTIONS method shouldn't be API job? I mean API should let the client know which options (GET, POST, UPDATE, PUT, etc.) are available. isn't this the whole point of CORS, pre-flight request and OPTIONS method? I think it's the API job to do that, specially in modern clients, not server