CORS cross-origin warning showing up in a PHP project

[NewMedia]

Now submitting username & password to login page creates this error on hosting server Apache Unix --

I understood that the choice to use or not use CORS only applies to choosing a Mobile application for Node.js in Wappler. I don't see why the server should now be looking for the Access Control header.

There are questions and different opinions about this CORS error in the forum but no conclusive direction of final resolution that I find.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://myownwebsite.de/trainings/dmxConnect/api/trainings.php. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 302.

This is the json from that api -- which just looks up a table -- no problems before today

  "SecurityProviders/security2",
  {
    "name": "",
    "module": "auth",
    "action": "restrict",
    "options": {
      "provider": "security2",
      "loginUrl": "/trainingslogin.php",
      "forbiddenUrl": "/trainingslogin.php"
    }
  },

[Apple]

CORS only applies to browsers as far as I’m aware (a mobile app might be a browser, but I’m not familiar with mobile apps)

The error you’re getting, it’s on the browser’s console, right?

A browser update could’ve began enforcing CORS, that’s why you now see this error

However, this issue should only happen if the domain of the page where’s located the login form is different of the domain the API is located, is this the case?

Or is this a mobile app?

[NewMedia]

As far as I guessing it is the host server SSL security certificate assignment at fault.

I am testing this app in a subdirectory folder of the mail url,
The Hosting docs in my panel say that the SSL certificate that applies to the main domain is globally extended to any other folder that is installed inside that main website files location.

But the security coverage was obviously not carried through to the next folder in the same path, the folder where the Wappler app is installed.

I am hassling with these guys. They’ve claimed before that this website was secured – my account shows it installed and activated along with ipv6 and good until 2023.

But I didn’t see all my browsers stop freaking out until an hour after I called it to their attention and had even to re-open a CLOSED ticket the techs had done.

I now wait for a after closing time Friday resolution.

Thank you for checking in on that, @Apple

[Apple]

Please note CORS is not related to SSL certificates at all

CORS is an unrelated safety feature, that prevents unauthorised domains from doing API calls unless on the same domain or an authorised one

The browser complains about a missing CORS header. This is not needed when the your web form is on the same domain you do the API call - is this the case?

Otherwise you need a CORS header, unsure if Wappler has an official way of doing so. This can be done at NodeJS level (probably on lib/server.js)

[NewMedia]

Actually, it is all about SSL SECURITY CERTIFICATES.

prevents unauthorised domains from doing API calls unless on the same domain or an authorised one

What is it that determines "authorized"? Who or what authority determines or "authorizes" those domains?

I had no problem with testing the Wappler app online until I then placed it all inside a folder in one of my Authorized Domains.

https://mylongtimeAuthorizedDomain.de/newwapplerapp/index.php

Cross domain errors from "unauthorized remote resource" happened immediately.

In the browser this Wappler app folder in my authorized domain showed that this folder in my authorized SSL certificated, activated domain url path was suddenly INSECURE.

I am in touch with my hosting company to resolve this. Their stated guarantee is that all folders inside the path of my main url folder inherit the same SSL security and that browser will show these links with a secure badge .

Then the apis in my pages, all "locally sourced" from included Wappler folders would not be seen as "cross-origin". And all my css, jquery, boostrap & image sources are locally accessed in online Wappler folders.

That's why I think the very definition of what CORS is about is impacted by the main url being protected and the wappler folder app is not, at the moment.

[Apple]

@NewMedia

Actually, it is all about SSL SECURITY CERTIFICATES.

You better be ready to back this up

@NewMedia

What is it that determines “authorized”? Who or what authority determines or “authorizes” those domains?

You define those authorizations through the HTTP header "Access-Control-Allow-Origin"

I thought this was a NodeJS project, so I missed giving out an easy solution, sorry about that. You can define this header like this:

<?php
header("Access-Control-Allow-Origin: *"); // allow all domains, FOR TESTING

Put this somewhere in an include that's globally included in all your pages

You could also solve this through .htaccess:

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
</IfModule>

@NewMedia

Then the apis in my pages, all “locally sourced” from included Wappler folders would not be seen as “cross-origin”.

I didn't understand this, are you saying you're able to talk to to the remote API from your local project?

[mebeingken]

If you come to find it is not about the certificate, this might also help you configure CORS:

[NewMedia]

Thank you for all your help.
As I titled this topic "showing up in a PHP project"
I wanted to signal this right at the top.

The .htacess tip does not work. It was one of the first I tried when it happened.
I also put the Php code in the headers of my pages within the hour I first had it happen.

But this would be an easy way to cheat, too. Too Easy.

As far as what I meant about

@NewMedia

Then the apis in my pages, all “locally sourced” from included Wappler folders would not be seen as “cross-origin”.

I didn’t understand this, are you saying you’re able to talk to to the remote API from your local project?

I was emphasizing that NONE of my apis could be from a Remote Source -- which is what the CORS warning is all about. Everything happened in reference to the BASE Apache server discovery.

No file, no link had any other base reference but my own domain url.

I got a reply back from the techs. They said I need to also include in my htaccess the Force RE-DIRECT to https

Please add the following to the .htaccess file:

RewriteEngine OnRewriteCond %{SERVER_PORT} !^443$ RewriteRule (.*) https: //%{HTTP_HOST}/$1 [R=301,L]

Which is usually part of the standard WordPress htaccess code.

Perhaps the Wappler generated .htaccess should also routnely include this.

I will add that code to my htaccess and see where I am after that.

I'm going to reply to this topic with one more point:

[NewMedia]

From my hosting server an interesting recommendation as I've been talking about .htaccess files :

`With Wordpress and some shop systems, redirection via .htaccess is not sufficient or can lead to problems. In this case, the redirection to https must be set in the backend of the respective system, instructions are available from the respective developer.

Use of HSTS (HTTP Strict Transport Security)

With HSTS you can inform your visitors' web browser that your website can only be reached via HTTPS for a defined future. This allows various attack scenarios (e.g. a downgrade attack) to be eliminated.

On our packages you can easily activate HSTS with the following line in a .htaccess file:

Header set Strict-Transport-Security "max-age=31536000"

The number in "max-age" is one year in seconds. This is the defined future mentioned at the beginning.`

[NewMedia]

Hi, Ken.

I believe the setting you are showing only shows up in a mobile or node.js project.

[mebeingken]

The screenshot is from a non-mobile php project using docker.

[NewMedia]

Thank you, @mebeingken and @Apple !

Just to refresh where my problem started:

I have to put a Wappler php/mysql application into a folder inside the main domain url folder. The base is already running a ****press installation.

The Wappler app has to sit in another folder inside the main domain folder --site root.

https://myproblemdomain.de/trainings (Wappler app lives separately here)

The CORS cross-origin problem that prevented Wappler from performing did turn out to be about permissions and “security”, part of it corrected by forcing https by default in the siute root .htaccess.

It appears that the CORS problem has been resolved by getting my hosting server to pitch in and properly activate my Security Certificate along the path of the main domain url.

And putting in the .htaccess file settings (in the root domain folder of the “home” index.php file)

that this particular Apache server responded to

#you do not need to add your domain to the script
#RewriteEngine OnRewriteCond %{SERVER_PORT} !^443$ RewriteRule (.*) https: //% mymainurl.de/$1 [R=301,L]
 
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]