Should I allow custom domains in CORS policy, safe? Our University has proxy server in front of our OJS server, on which one do I config to allow CORS policy (my OJS server or Proxy server), notice that I do not have access to University proxy server.
If the proxying is happening in Apache, it’d be good to know what the ProxyPass and ProxyPassReverse rules are, as well as any potential mod_rewrite rules they may be using.
If you like, and can provide me with an account in one of these installations, I can try working in a test submission and see if I can debug anything further.
-Proxy server is not on the same OJS server or happening in Apache, it is University wide proxy server.
-I am going to send your mod_rewrite rules on different chanel
-I am contacting my University Proxy Server admin staff to ask related questions
-I have dev.journalhosting.ucalgary.ca server where it shares the same University Proxy Server but it does not use custom domain and it seems to upload files a bit better - more files can be uploaded on this server but some still fails, you can have access to it if you want. It is a sandbox
So I am almost positive I know what this is. Dung, your journals that are on custom URLs also remove index.php (as well as the journal path) from the URL using mod_ rewrite and OJS’ support of RESTful URLs. That’s all fine, but you need to be careful with the API calls when you redirect them. This is what is happening, and Nate was correct when he drew attention to the 302 redirect that was occurring when you uploaded a file.
Because your POST requests do not contain index.php or the path (in this case “rcc”) your POST urls look like:
/api/v1/submissions/74533/files
and you have a RewriteRule in the configuration file you sent me of:
# Rewrite custom domain to make api calls correctly
RewriteRule ^/(api/.*)$ /index.php/rcc/$1 [R,L]
Which is fine, but by default RewriteRules switch to a GET request, and lose all of your POST material so the reason why the files are not uploading is because all you end up doing is just fetching the /files end point in the API again, on a 302 redirect.
You can see the redirect and the response happen if you just try loading:
In a browser if you are logged in. You’ll see the redirect occur and you’ll just get back some empty JSON.
There is a special HTTP status code of 307 that you can use to force browsers to make the request again, using the original protocol and original post data. I suspect you will get success if you change the rule above to:
# Rewrite custom domain to make api calls correctly
RewriteRule ^/(api/.*)$ /index.php/rcc/$1 [R=307,L]
which tells Apache to use the 307 HTTP status code when sending the Location header.
I should as well point out that a 307 status code is meant to be a “temporary redirect” so this might be a misuse of it. I suspect the long term solution here is to not obfuscate or rewrite your API urls. At PKPPS we do not do this, as it leads to weird problems that are hard to debug.
@jnugent We can call this file 71007.pdf (i sent you) earlier an exception and move on, but if you can try to upload it you will see it will not upload? What should I look at?
Here is a short story how I found out and fix the issue:
"
Hi Dung,
Not sure if this helps but the pdf file 71007 that won’t upload was created using LaTeX and the user says that when they remove the graphics generated in a eps format the file uploads fine. However, because it is a mathematics journal eps graphics are essential for publication.
Thanks,
Kate
"
So I googled and then contacted my network Proxy server F5 admin team and they just quickly allowed content thru filter and that works!
Here is the error when it did not work.
Thank you so much Jason and Nate. We really appreciate your work and OJS. All is good now. ticket can be closed.