safari xmlhttprequest access control checks

XMLHttpRequest cannot load ... due to access control checks

not sure whats wrong… here the app.js header:

and where I call the API:

and the API call function in the app.js:

Have in mind that most of the endpoints (and associated scopes) associated with the Management API are intended for sensitive operation that allow to completely manage/control a specific tenant. The implications it that most of these endpoints and action are also not suitable to be invoked directly from a browser application.

In other words, in order to obtain an access token applicable for most operation in this API you need to perform a client credentials grant as most scopes will not be granted in end-user based flows like the one you are initiating in your application. A client credentials grant implies a confidential client which excludes browser-based application so if most of the scopes ( read:users being one of them) require a confidential client and a browser-based application cannot be a confidential client it is not really relevant what the Management API supports in terms of CORS requests ( the error you’re getting is a CORS related error ).

In conclusion, you’ll need to change your approach as Management API is mostly not meant to be called directly from a browser application. In your specific application you could either:

• obtain an access token with client credentials from your own back-end and then from the SPA call your back-end ( lots of responsibility for you here, as you would need to ensure that calls to your backed are properly authorized ).
• make use of custom claims ( OpenID Connect Scopes ) to surface user metadata information directly in ID tokens or /userinfo endpoint response. This way the client application could get the relevant information either from the ID token or the user information endpoint and not have to call Management API.

The second point would likely be the general recommendation to meet your requirements.

I understand your point about the documentation; the reality is that there’s some flexibility and different ways to achieve the same end-goal. Depending on the scenario one may be better suited than other, but then this complicates reference documentation which needs to cover what’s available, but may fail to cover all the scenarios where one should be used versus the other.

In relation to the problem at hand, I hate to do this, but if creating/updating is also part of the equation then the general recommendation I made before may even need to be revisited. For purely read access I would maintain that ID token or /userinfo are likely the simplest way to get the information.

However, if the client application will also be managing it then it depends… will you be needing to manage just user_metadata or also app_metadata entries?

Both user meta data (what the user is learning, what city he/she lives in, etc.) and app meta data (activity points, based on which the user level gets calculated & the selected plan, based on if the user upgraded/ downgraded or not. Guess gonna use stripe for the payments)

Given that the application will be managing app_metadata and this requires a Management API access token obtained through client credentials then you’re guaranteed to be required to have a backend from where you could perform this.

Assuming a backend is present and that backend already has logic to call Management API (for updating app_metadata purposes) then my recommendation is that this backend exposes endpoints that allow the SPA part of the application to update user_metadata for the current user.

The high-level flow would be the following:

• end-user authenticates and chooses to update their profile.
• the application calls a custom endpoint in your backend that allows to update user_metadata based on the data received from the SPA.
• the backend validates that the call is authenticated (this may either be through a token or a cookie based session).
• from either the token or cookie based session the backend knows who is the user currently authenticated so uses a client credentials access token to call the Management API and update the user metadata for that specific user.

Any documentations for Django to make this happen? Or do I need to add NodeJS to my server as well?

I confess I’m not an expert on Python (far from it actually), but for the part about calling Management API from a Python-based backend you can check the Python SDK ( GitHub - auth0/auth0-python: Auth0 SDK for Python ).

• Skip to main content
• Select language
• Skip to search
• HTTP access control (CORS)

Preflighted requests and redirects

Credentialed requests and wildcards.

• Access-Control-Allow-Headers
• Access-Control-Request-Headers

Compatibility notes

A resource makes a cross-origin HTTP request when it requests a resource from a different domain, protocol, or port to its own. For example, an HTML page served from http://domain-a.com makes an <img> src request for http://domain-b.com/image.jpg. Many pages on the web today load resources like CSS stylesheets, images, and scripts from separate domains.

For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest and Fetch follow the same-origin policy . So, a web application using XMLHttpRequest or Fetch could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow cross-domain requests.

The Cross-Origin Resource Sharing ( CORS ) mechanism gives web servers cross-domain access controls, which enable secure cross-domain data transfers. Modern browsers use CORS in an API container - such as XMLHttpRequest or Fetch - to mitigate risks of cross-origin HTTP requests.

This article is for web administrators, server developers, and front-end developers. Modern browsers handle the client-side components of cross-origin sharing, including headers and policy enforcement. But this new standard means servers have to handle new request and response headers. Another article for server developers discussing cross-origin sharing from a server perspective (with PHP code snippets) is supplementary reading.

This cross-origin sharing standard is used to enable cross-site HTTP requests for:

• Invocations of the XMLHttpRequest or Fetch APIs in a cross-site manner, as discussed above.
• Web Fonts (for cross-domain font usage in @font-face within CSS), so that servers can deploy TrueType fonts that can only be cross-site loaded and used by web sites that are permitted to do so.
• WebGL textures .
• Images/video frames drawn to a canvas using drawImage .
• Stylesheets (for CSSOM access).
• Scripts (for unmuted exceptions).

This article is a general discussion of Cross-Origin Resource Sharing and includes a discussion of the necessary HTTP headers.

The Cross-Origin Resource Sharing standard works by adding new HTTP headers that allow servers to describe the set of origins that are permitted to read that information using a web browser.  Additionally, for HTTP request methods that can cause side-effects on server's data (in particular, for HTTP methods other than GET , or for POST usage with certain MIME types ), the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP OPTIONS request method, and then, upon "approval" from the server, sending the actual request with the actual HTTP request method. Servers can also notify clients whether "credentials" (including Cookies and HTTP Authentication data) should be sent with requests.

Subsequent sections discuss scenarios, as well as provide a breakdown of the HTTP headers used. 

Examples of access control scenarios

Here, we present three scenarios that illustrate how Cross-Origin Resource Sharing works. All of these examples use the XMLHttpRequest object, which can be used to make cross-site invocations in any supporting browser.

The JavaScript snippets included in these sections (and running instances of the server-code that correctly handles these cross-site requests) can be found "in action" at http://arunranga.com/examples/access-control/ , and will work in browsers that support cross-site XMLHttpRequest .

A discussion of Cross-Origin Resource Sharing from a server perspective (including PHP code snippets) can be found in the Server-Side Access Control (CORS) article.

Simple requests

Some requests don’t trigger a CORS preflight . Those are called “simple requests” in this article, though the Fetch spec (which defines CORS) doesn’t use that term. A request that doesn’t trigger a CORS preflight —a so-called “simple request”—is one that meets all the following conditions:

• Accept-Language
• Content-Language
• Content-Type (but note the additional requirements below)
• Viewport-Width
• application/x-www-form-urlencoded
• multipart/form-data

For example, suppose web content on domain http://foo.example wishes to invoke content on domain http://bar.other . Code of this sort might be used within JavaScript deployed on foo.example:

This will lead to a simple exchange between the client and the server, using CORS headers to handle the privileges:

Let us look at what the browser will send the server in this case, and let's see how the server responds:

Lines 1 - 10 are headers sent. The main HTTP request header of note here is the Origin header on line 10 above, which shows that the invocation is coming from content on the domain http://foo.example .

Lines 13 - 22 show the HTTP response from the server on domain http://bar.other . In response, the server sends back an Access-Control-Allow-Origin header, shown above in line 16. The use of the Origin header and of Access-Control-Allow-Origin show the access control protocol in its simplest use. In this case, the server responds with a Access-Control-Allow-Origin: * which means that the resource can be accessed by any domain in a cross-site manner. If the resource owners at http://bar.other wished to restrict access to the resource to requests only from http://foo.example , they would send back:

Access-Control-Allow-Origin: http://foo.example

Note that now, no domain other than http://foo.example (identified by the ORIGIN: header in the request, as in line 10 above) can access the resource  in a cross-site manner.  The Access-Control-Allow-Origin header should contain the value that was sent in the request's Origin header. 

Preflighted requests

Unlike “simple requests” (discussed above) , "preflighted" requests first send an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data.

In particular, a request is preflighted if any of the following conditions is true:

The following is an example of a request that will be preflighted.

In the example above, line 3 creates an XML body to send with the POST request in line 8.  Also, on line 9, a "customized" (non-standard) HTTP request header is set ( X-PINGOTHER: pingpong ).  Such headers are not part of the HTTP/1.1 protocol, but are generally useful to web applications.  Since the request uses a Content-Type of application/xml , and since a custom header is set, this request is preflighted.

Let's take a look at the full exchange between client and server. The first exchange is the preflight request/response :

Once the preflight request is complete, the real request is sent:

Lines 1 - 12 above represent the preflight request with the OPTIONS method. The browser determines that it needs to send this based on the request parameters that the JavaScript code snippet above was using, so that the server can respond whether it is acceptable to send the request with the actual request parameters. OPTIONS is an HTTP/1.1 method that is used to determine further information from servers, and is a safe method, meaning that it can't be used to change the resource. Note that along with the OPTIONS request, two other request headers are sent (lines 10 and 11 respectively):

The Access-Control-Request-Method header notifies the server as part of a preflight request that when the actual request is sent, it will be sent with a POST request method. The Access-Control-Request-Headers header notifies the server that when the actual request is sent, it will be sent with a  X-PINGOTHER  and Content-Type custom headers. The server now has an opportunity to determine whether it wishes to accept a request under these circumstances.

Lines 14 - 26 above are the response that the server sends back indicating that the request method ( POST ) and request headers ( X-PINGOTHER ) are acceptable. In particular, let's look at lines 17-20:

The server responds with Access-Control-Allow-Methods and says that POST , GET , and OPTIONS are viable methods to query the resource in question. Note that this header is similar to the Allow response header, but used strictly within the context of access control.

The server also sends Access-Control-Allow-Headers with a value of " X-PINGOTHER, Content-Type ", confirming that these are permitted headers to be used with the actual request. Like Access-Control-Allow-Methods , Access-Control-Allow-Headers is a comma separated list of acceptable headers.

Finally, Access-Control-Max-Age gives the value in seconds for how long the response to the preflight request can be cached for without sending another preflight request. In this case, 86400 seconds is 24 hours. Note that each browser has a maximum internal value that takes precedence when the  Access-Control-Max-Age  is greater.

Most browsers currently don’t support following redirects for preflighted requests. If a redirect occurs for a preflighted request, most current browsers will report an error message such as the following.

The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight

Request requires preflight, which is disallowed to follow cross-origin redirect

The CORS protocol originally required that behavior but was subsquently changed to no longer require it . However, most browsers have not yet implemented the change and still exhibit the behavior that was originally required.

So until browsers catch up with the spec, you may be able to work around this limitation by doing one or both of the following:

• change the server-side behavior to avoid the preflight and/or to avoid the redirect—if you have control over the server the request is being made to
• change the request such that it is a simple request that doesn’t cause a preflight

But if it’s not possible to make those changes, then another way that may be possible is to this:

• Make a simple request to determine (using Response.url for the Fetch API, or XHR.responseURL to determine what URL the real preflighted request would end up at).
• Make another request (the “real” request) using the URL you obtained from Response.url or XMLHttpRequest.responseURL in the first step.

However, if the request is one that triggers a preflight due to the presence of the `Authorization` header in the request, you won’t be able to work around the limitation using the steps above. And you won’t be able to work around it at all unless you have control over the server the request is being made to.

Requests with credentials

The most interesting capability exposed by both XMLHttpRequest or Fetch and CORS is the ability to make "credentialed" requests that are aware of HTTP cookies and HTTP Authentication information. By default, in cross-site XMLHttpRequest or Fetch invocations, browsers will not send credentials. A specific flag has to be set on the XMLHttpRequest object or the Request constructor when it is invoked.

In this example, content originally loaded from http://foo.example makes a simple GET request to a resource on http://bar.other which sets Cookies. Content on foo.example might contain JavaScript like this:

Line 7 shows the flag on XMLHttpRequest that has to be set in order to make the invocation with Cookies, namely the withCredentials boolean value. By default, the invocation is made without Cookies. Since this is a simple GET request, it is not preflighted, but the browser will reject any response that does not have the Access-Control-Allow-Credentials : true header, and not make the response available to the invoking web content.

Here is a sample exchange between client and server:

Although line 11 contains the Cookie destined for the content on http://bar.other , if bar.other did not respond with an Access-Control-Allow-Credentials : true (line 19) the response would be ignored and not made available to web content.

When responding to a credentialed request, the server must specify an origin in the value of the Access-Control-Allow-Origin header, instead of specifying the " * " wildcard.

Because the request headers in the above example include a Cookie header, the request would fail if the value of the Access-Control-Allow-Origin header were "*". But it does not fail: Because the value of the Access-Control-Allow-Origin header is " http://foo.example " (an actual origin) rather than the " * " wildcard, the credential-cognizant content is returned to the invoking web content.

Note that the Set-Cookie response header in the example above also sets a further cookie. In case of failure, an exception—depending on the API used—is raised.

The HTTP response headers

This section lists the HTTP response headers that servers send back for access control requests as defined by the Cross-Origin Resource Sharing specification. The previous section gives an overview of these in action.

• Access-Control-Allow-Origin

A returned resource may have one Access-Control-Allow-Origin header, with the following syntax:

The origin parameter specifies a URI that may access the resource. The browser must enforce this. For requests without credentials, the server may specify "*" as a wildcard, thereby allowing any origin to access the resource.

For example, to allow http://mozilla.org to access the resource, you can specify:

If the server specifies an origin host rather than "*", then it could also include Origin in the Vary response header to indicate to clients that server responses will differ based on the value of the Origin request header.

• Access-Control-Expose-Headers

The Access-Control-Expose-Headers header lets a server whitelist headers that browsers are allowed to access. For example:

This allows the X-My-Custom-Header and X-Another-Custom-Header headers to be exposed to the browser.

• Access-Control-Max-Age

The  Access-Control-Max-Age header indicates how long the results of a preflight request can be cached. For an example of a preflight request, see the above examples.

The delta-seconds parameter indicates the number of seconds the results can be cached.

• Access-Control-Allow-Credentials

The Access-Control-Allow-Credentials header Indicates whether or not the response to the request can be exposed when the credentials flag is true.  When used as part of a response to a preflight request, this indicates whether or not the actual request can be made using credentials. Note that simple GET requests are not preflighted, and so if a request is made for a resource with credentials, if this header is not returned with the resource, the response is ignored by the browser and not returned to web content.

Credentialed requests are discussed above.

• Access-Control-Allow-Methods

The Access-Control-Allow-Methods header specifies the method or methods allowed when accessing the resource. This is used in response to a preflight request. The conditions under which a request is preflighted are discussed above.

An example of a preflight request is given above , including an example which sends this header to the browser.

The Access-Control-Allow-Headers header is used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.

The HTTP request headers

This section lists headers that clients may use when issuing HTTP requests in order to make use of the cross-origin sharing feature. Note that these headers are set for you when making invocations to servers. Developers using cross-site XMLHttpRequest capability do not have to set any cross-origin sharing request headers programmatically.

The Origin header indicates the origin of the cross-site access request or preflight request.

The origin is a URI indicating the server from which the request initiated.  It does not include any path information, but only the server name.

Note that in any access control request, the Origin header is always sent.

• Access-Control-Request-Method

The Access-Control-Request-Method is used when issuing a preflight request to let the server know what HTTP method will be used when the actual request is made.

Examples of this usage can be found above.

The Access-Control-Request-Headers header is used when issuing a preflight request to let the server know what HTTP headers will be used when the actual request is made.

Examples of this usage can be found above .

Specifications

Browser compatibility.

The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.

• Internet Explorer 8 and 9 expose CORS via the XDomainRequest object, but have a full implementation in IE 10. 
• While Firefox 3.5 introduced support for cross-site XMLHttpRequests and Web Fonts, certain requests were limited until later versions. Specifically, Firefox 7 introduced the ability for cross-site HTTP requests for WebGL Textures, and Firefox 9 added support for Images drawn on a canvas using drawImage .
• Code Samples Showing XMLHttpRequest and Cross-Origin Resource Sharing
• Cross-Origin Resource Sharing From a Server-Side Perspective (PHP, etc.)
• Cross-Origin Resource Sharing specification
• XMLHttpRequest
• Using CORS with All (Modern) Browsers
• Using CORS - HTML5 Rocks

Document Tags and Contributors

• Same-origin policy
• Identifying resources on the Web
• Introduction to MIME Types
• Complete list of MIME Types
• Choosing between www and non-www URLs
• Overview of HTTP
• Evolution of HTTP
• HTTP Messages
• A typical HTTP session
• Connection management in HTTP/1.x
• Content Security Policy (CSP)
• HTTP Public Key Pinning (HPKP)
• HTTP Strict Transport Security (HSTS)
• Cookie security
• X-Content-Type-Options
• X-Frame-Options
• X-XSS-Protection
• Mozilla web security guidelines
• Mozilla Observatory
• HTTP authentication
• HTTP caching
• HTTP compression
• HTTP conditional requests
• HTTP content negotiation
• HTTP cookies
• HTTP range requests
• HTTP redirects
• HTTP specifications
• References:
• Accept-Charset
• Accept-Encoding
• Accept-Ranges
• Authorization
• Cache-Control
• Content-Disposition
• Content-Encoding
• Content-Length
• Content-Location
• Content-Range
• Content-Security-Policy
• Content-Security-Policy-Report-Only
• Content-Type
• If-Modified-Since
• If-None-Match
• If-Unmodified-Since
• Large-Allocation
• Last-Modified
• Proxy-Authenticate
• Proxy-Authorization
• Public-Key-Pins
• Public-Key-Pins-Report-Only
• Referrer-Policy
• Retry-After
• Set-Cookie2
• Strict-Transport-Security
• Transfer-Encoding
• Upgrade-Insecure-Requests
• WWW-Authenticate
• X-DNS-Prefetch-Control
• X-Forwarded-For
• X-Forwarded-Host
• X-Forwarded-Proto
• , <iframe> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites."> X-Frame-Options
• 100 Continue
• 101 Switching Protocol
• 201 Created
• 202 Accepted
• 203 Non-Authoritative Information
• 204 No Content
• 205 Reset Content
• 206 Partial Content
• 300 Multiple Choices
• 301 Moved Permanently
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect
• 400 Bad Request
• 401 Unauthorized
• 403 Forbidden
• 404 Not Found
• 405 Method Not Allowed
• 406 Not Acceptable
• 407 Proxy Authentication Required
• 408 Request Timeout
• 409 Conflict
• 411 Length Required
• 412 Precondition Failed
• 413 Payload Too Large
• 414 URI Too Long
• 415 Unsupported Media Type
• 416 Range Not Satisfiable
• 417 Expectation Failed
• 426 Upgrade Required
• 428 Precondition Required
• 429 Too Many Requests
• 431 Request Header Fields Too Large
• 451 Unavailable For Legal Reasons
• 500 Internal Server Error
• 501 Not Implemented
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout
• 505 HTTP Version Not Supported
• 511 Network Authentication Required
• element. If this value is absent, then any URI is allowed. If this directive is absent, the user agent will use the value in the <base> element."> CSP: base-uri
• CSP: block-all-mixed-content
• and <iframe>. For workers, non-compliant requests are treated as fatal network errors by the user agent."> CSP: child-src
• CSP: connect-src
• CSP: default-src
• CSP: font-src
• CSP: form-action
• , <iframe>, <object>, <embed>, or <applet>."> CSP: frame-ancestors
• and <iframe>."> CSP: frame-src
• CSP: img-src
• CSP: manifest-src
• and <video> elements."> CSP: media-src
• , <embed>, and <applet> elements."> CSP: object-src
• CSP: plugin-types
• CSP: referrer
• CSP: report-uri
• CSP: require-sri-for
• sandbox attribute. It applies restrictions to a page's actions including preventing popups, preventing the execution of plugins and scripts, and enforcing a same-origin policy."> CSP: sandbox
• elements, but also things like inline script event handlers (onclick) and XSLT stylesheets which can trigger script execution."> CSP: script-src
• CSP: style-src
• CSP: upgrade-insecure-requests
• CSP: worker-src

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encountered "due to access control checks." error when requesting on macos #4113

CarbonPool commented May 13, 2022

lucasfernog commented May 15, 2022

Sorry, something went wrong.

lucasfernog commented Jun 20, 2022

primeagen-rustaceans commented Jul 4, 2023 • edited

FabianLars commented Jul 4, 2023

Primeagen-rustaceans commented jul 6, 2023 • edited.

No branches or pull requests

XmlHttpRequest upload sometimes fail "due to access control checks"

I work on a website where users can upload files to the server via POST - all requests are handled within the same site, so no CORS come into play.

With Safari on iOS 10, the call often is aborted and the console says: "cannot load '/UploadFile.ashx' due to access control checks"

We detect this error in our JS code and retry the exact same request with success.

All other browsers/OS work fine - even Safari on Mac.

We tried so far:

• Uploading the file object from the file input
• Uploading the FileReader.result after loading the file
• Uploading the FileReader.result as an encoded string of a text input field in a dynamic html form

I saw similar questions on different dev support pages - but all without any answer/solution so far.

XMLHTTPRequest cannot load URL_HERE due to access control checks

Since a few weeks I’ve been noticing an issue when saving new or editing posts and stuff in CP. I’m not sure what’s going wrong, or what causes it. But it seems to have something to do with Cookie (or their policies) or CORS. I don’t really understand the problem yet and my hosting provider is a twat in explaining anything blaming everything but themselves - Not very helpful in even understanding what’s going wrong…

Expected behavior

When I click ‘Save as Draft’ or ‘Publish’ that the posts savespublishes

Current behavior

It starts loading/saving, stalls and eventually times out on a white screen. If you look in console it gives a non descript error:

Screenshot: https://disk.stor.fit/index.php/s/7tcJ4GmzeTQ2zC7

Possible solution

No idea - According to my hosting provider something with cookies. THey put the following in .htaccess:

Header always edit Set-Cookie (.*) “$1;HttpOnly;Secure;samesite=lax”

But that didn’t help

Steps to reproduce

As described, save a page/post/product (in CC) and eventually it starts stalling and giving that error. Sometimes this happens after a few times saving (say 3-5) other times after 15+ times.

Akin to a stupid firewall blocking repeated requests. Though I’m assured it’s not a firewall.

I’ve tried and seen the issue in Safari 15.x and Firefox 102 (macOS).

I have several sites on CP and most work fine. So far I’ve only noticed this only on ONE of the sites, but that’s also the one I edit and post on the most currently, so perhaps all of them have it but I don’t do enough to it to cause the issue.

It’s super frustrating though. Anyone else has this problem? What do I do about it? Where is the issue? CP? Server? Browser?

This shouldn’t be an issue in ClassicPress. Especially if nothing has changed when this issue showed up. Sometimes a change to server configuration can cause unintended consequences.

Let’s try enabling CORS and see if that helps. Add the following to the top of your .htaccess file:

Header set Access-Control-Allow-Origin "*"

If that doesn’t work, also try this version:

Header add Access-Control-Allow-Origin "*"

See if that works. Let us know.

I haven’t seen this before. But are you sure that everything on your site is set to https (and not http ) and also that you are consistent about whether you have a www. or not at the beginning of your website URL?

You should have your host remove what they did, because that’s opening a security issue. What they could try instead is replacing it with this: Access-Control-Allow-Headers: Origin

Will do, thanks for the quick reply!

Yes, I use the force https thing in wp-config.php and also have a forced redirect in .htaccess that works pretty good. So that’s not the issue.

I’m not sure if it’s a new thing or that it always was happening but i just didn’t notice it before. I rent this VPS and have done so for 2 years now. Several sites on it. And all seems well - Except for this issue.

I just looked at the .htaccess - The first line is already in there, has been since day one. I have had this stuff in there for at least a year now.

At the very top, the recent changes/suggestions. But that seems redundant now.

And then the ‘wordpress’ bit and a few redirects below it

Same issue with this added:

Header add Access-Control-Allow-Origin “*”

Of-course I commented out the other 2 lines.

Can you test the default .htaccess configuration, please? If the issue persists with default htaccess, we will at least eliminate any custom rules added to htaccess. So we can focus on other areas to troubleshoot.

The easiest way to do this. Rename current .htaccess file to htaccess.txt. Then create a new .htaccess and add the following:

Once saved. Test to see if issue is gone or not.

Hah yes! I just tried this:

Then added your suggested line from before above it. Both failed on the first save attempt.

Keep in mind that all that .htaccess stuff worked fine for months. I use a almost identical version of it on another site and don’t see this issue there (yet/or at all).

In my ticket to the hosting company I at first suspected the firewall - As that’s a thing they messed with a few months ago. Partly because it works on my other site (on a different vps) but also because both sites aside from a bunch of plugins are set up the same, same htaccess, same php/modules/whatever as far as i can control that.

Have you checked your Apache error log to see if admin-ajax.php requests show any server-side errors?

Also, can you test if admin-ajax.php requests are being blocked in the frontend?

I’m not sure how to test admin-ajax.php in the front-end I’m not overly familiar with it - I don’t think my site/theme does much admin-ajax-y there. There are a few references to it in the source, for adding things to the shopping cart for example (Classic commerce), but that works fine as far as I can tell.

Check it out - The site is fairly straightforward without much gimmicks really: https://mototravel.net

I’m still not sure what the problem is or what to do about it. Anyone got an idea what the issue so I can accurately search for a solution?

You know, understanding the problem is half the solution and that sort of thing…

@arnandegans Took a look at your robots.txt file and it shows:

Should be something like:

Notice the https

Don’t know if this is even relevant, but may be something to look into. Your Disallow entries are not needed.

Could this possibly be a modsecurity issue?

I don’t know - I guess that’s what I’m asking you guys. If I google the error I find all kinds of stuff for iOS apps and http/post requests, but nothing useful that applies to WordPress/ClassicPress and some talk about ‘symfony’ being outdated. Whatever that means.

If you have cPanel access, you should be able to turn off ModSecurity in order to try your update again. If it works with ModSec off, you should first turn it back on, then contact your webhost to see if they can tweak it so you can still have ModSec protection while also being able to save edits.

In any case, this seems to me to be a hosting environment issue, rather than a CP issue.

Its a VPS I have cPanel and WHM root access. I’ll look for the option.

I too am not convinced its a CP issue, but my webhost is less than helpful. They barely answer tickets…

Found it, disabled it for all domains, waited a few seconds and tried to save my post a few times. Still not working.

Can it be a firewall thing? And if so, how do I check that? As far as I know, aside from regular updates to cPanel, that’s the only thing that got messed with in the past 6 months.

If it was ModSec issue, it would have made an immediate difference. Could be a firewall issue; it definitely has to do with security. Sorry I don’t have the expertise to be more helpful.

Seems to be a browser issue involving a javascript conflict. Have you seen this?

Electrostal History and Art Museum

Most Recent: Reviews ordered by most recent publish date in descending order.

Detailed Reviews: Reviews ordered by recency and descriptiveness of user-identified themes such as wait time, length of visit, general tips, and location information.

Electrostal History and Art Museum - All You Need to Know BEFORE You Go (2024)

• (0.19 mi) Elektrostal Hotel
• (1.21 mi) Yakor Hotel
• (1.27 mi) Mini Hotel Banifatsiy
• (1.18 mi) Elemash
• (1.36 mi) Hotel Djaz
• (0.07 mi) Prima Bolshogo
• (0.13 mi) Makecoffee
• (0.25 mi) Amsterdam Moments
• (0.25 mi) Pechka
• (0.26 mi) Mazhor

Phone: +90 (212) 875 19 08

• E-Mail: [email protected]

• Company Profile
• Company Policy
• Mission and Vision
• Certificates
• Aluminium Windows
• Aluminium Doors
• Aluminium Sliding Elements
• Aluminium Curtain Walls
• Aluminium Skylight Elements
• Aluminium Frames for Safety and Security
• Aluminium Conservatories
• Metal Panel Sheet Claddings
• Aluminium Entrance Frames
• Glass Structures
• Complementary Items
• Lightweight Steel Structures
• Human Resources OPEN

Mimsa Aluminium - Istanbul

Fasad Stroy - Moscow

Contact Form

Address: bosb mermerciler san. sitesi 4. cadde no: 7 34520, beylikduzu / istanbul / turkey, fax: +90 (212) 875 58 17, email: [email protected], address: gorkogo street 38, elektrostal - moscow region / russia, phone: +7 (495) 748 07 95.