Small issue with AJAX, XMLHttpRequest and CORS about issue-archive HOT 12 OPEN

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

from issue-archive.

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

Other thoughts, anyone?

from issue-archive.

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

from issue-archive.

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?

from issue-archive.

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.

from issue-archive.

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.

from issue-archive.

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

from issue-archive.

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

from issue-archive.

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.

from issue-archive.

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.

from issue-archive.

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

from issue-archive.

OK.

from issue-archive.