Javascript 请求的资源上不存在“Access-Control-Allow-Origin”标头——尝试从 REST API 获取数据时

Question

提问by daniel.lozynski

I'm trying to fetch some data from the REST API of HP Alm. It works pretty well with a small curl script - I get my data.

我正在尝试从 HP Alm 的 REST API 获取一些数据。它与一个小的 curl 脚本配合得很好 - 我得到了我的数据。

Now doing that with JavaScript, fetch and ES6 (more or less) seems to be a bigger issue. I keep getting this error message:

现在使用 JavaScript、fetch 和 ES6（或多或少）这样做似乎是一个更大的问题。我不断收到此错误消息：

Fetch API cannot load . Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://127.0.0.1:3000' is therefore not allowed access. The response had HTTP status code 501. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

获取 API 无法加载 . 对预检请求的响应未通过访问控制检查：请求的资源上不存在“Access-Control-Allow-Origin”标头。因此不允许访问源“ http://127.0.0.1:3000”。响应的 HTTP 状态代码为 501。如果不透明响应满足您的需求，请将请求的模式设置为“no-cors”以在禁用 CORS 的情况下获取资源。

I understand that this is because I am trying to fetch that data from within my localhost and the solution should be using CORS. Now I thought I actually did that, but somehow it either ignores what I write in the header or the problem is something else?

我知道这是因为我试图从我的本地主机中获取该数据，并且解决方案应该使用 CORS。现在我以为我真的这样做了，但不知何故它要么忽略了我在标题中写的内容，要么问题出在别的地方？

So, is there an implementation issue? Am I doing it wrong? I can't check the server logs unfortunately. I'm really a bit stuck here.

那么，是否存在实施问题？我做错了吗？不幸的是，我无法检查服务器日志。我真的有点卡在这里了。

function performSignIn() {

  let headers = new Headers();

  headers.append('Content-Type', 'application/json');
  headers.append('Accept', 'application/json');

  headers.append('Access-Control-Allow-Origin', 'http://localhost:3000');
  headers.append('Access-Control-Allow-Credentials', 'true');

  headers.append('GET', 'POST', 'OPTIONS');

  headers.append('Authorization', 'Basic ' + base64.encode(username + ":" + password));

  fetch(sign_in, {
      //mode: 'no-cors',
      credentials: 'include',
      method: 'POST',
      headers: headers
    })
    .then(response => response.json())
    .then(json => console.log(json))
    .catch(error => console.log('Authorization failed : ' + error.message));
}

I am using Chrome. I also tried using that Chrome CORS Plugin, but then I am getting another error message:

我正在使用 Chrome。我也尝试使用该 Chrome CORS 插件，但随后我收到另一条错误消息：

The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. Origin 'http://127.0.0.1:3000' is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

当请求的凭据模式为“包含”时，响应中“Access-Control-Allow-Origin”标头的值不得为通配符“*”。因此不允许访问源“ http://127.0.0.1:3000”。XMLHttpRequest 发起的请求的凭证模式由 withCredentials 属性控制。

Answer 1

回答by sideshowbarker

This answer covers a lot of ground, so it's divided into three parts:

这个答案涵盖了很多方面，所以它分为三个部分：

How to use a CORS proxy to get around “No Access-Control-Allow-Origin header”problems
How to avoid the CORS preflight
How to fix “Access-Control-Allow-Origin header must not be the wildcard”problems

如何使用 CORS 代理解决“No Access-Control-Allow-Origin header”问题
如何避免 CORS 预检
如何解决“Access-Control-Allow-Origin 标头不能是通配符”问题

How to use a CORS proxy to get around “No Access-Control-Allow-Origin header”problems

如何使用 CORS 代理解决“No Access-Control-Allow-Origin header”问题

If you don't control the server your frontend JavaScript code is sending a request to, and the problem with the response from that server is just the lack of the necessary Access-Control-Allow-Originheader, you can still get things to work—by making the request through a CORS proxy. To show how that works, first here's some code that doesn't use a CORS proxy:

如果您不控制前端 JavaScript 代码向其发送请求的服务器，并且来自该服务器的响应的问题只是缺少必要的Access-Control-Allow-Origin标头，您仍然可以通过CORS 代理。为了展示它是如何工作的，首先这里有一些不使用 CORS 代理的代码：

const url = "https://example.com"; // site that doesn't send Access-Control-*
fetch(url)
.then(response => response.text())
.then(contents => console.log(contents))
.catch(() => console.log("Can't access " + url + " response. Blocked by browser?"))

The reason the catchblock gets hit there is, the browser prevents that code from accessing the response which comes back from https://example.com. And the reason the browser does that is, the response lacks the Access-Control-Allow-Originresponse header.

catch块被击中的原因是，浏览器阻止该代码访问从https://example.com. 浏览器这样做的原因是，响应缺少Access-Control-Allow-Origin响应标头。

Now, here's exactly the same example but just with a CORS proxy added in:

现在，这是完全相同的示例，但只是添加了 CORS 代理：

const proxyurl = "https://cors-anywhere.herokuapp.com/";
const url = "https://example.com"; // site that doesn't send Access-Control-*
fetch(proxyurl + url) // https://cors-anywhere.herokuapp.com/https://example.com
.then(response => response.text())
.then(contents => console.log(contents))
.catch(() => console.log("Can't access " + url + " response. Blocked by browser?"))

Note: If https://cors-anywhere.herokuapp.com is down or unavailable when you try it, then see below for how to deploy your own CORS Anywhere server at Heroku in just 2-3 minutes.

注意：如果 https://cors-anywhere.herokuapp.com 在您尝试时已关闭或不可用，请参阅下文了解如何在 2-3 分钟内在 Heroku 上部署您自己的 CORS Anywhere 服务器。

The second code snippet above can access the response successfully because taking the request URL and changing it to https://cors-anywhere.herokuapp.com/https://example.com—by just prefixing it with the proxy URL—causes the request to get made through that proxy, which then:

上面的第二个代码片段可以成功访问响应，因为获取请求 URL 并将其更改为https://cors-anywhere.herokuapp.com/https://example.com——只需在它前面加上代理 URL——会导致请求通过该代理进行，然后：

Forwards the request to https://example.com.
Receives the response from https://example.com.
Adds the Access-Control-Allow-Originheader to the response.
Passes that response, with that added header, back to the requesting frontend code.

将请求转发到https://example.com.
接收来自的响应https://example.com。
将Access-Control-Allow-Origin标头添加到响应中。
将带有添加的标头的响应传递回请求前端代码。

The browser then allows the frontend code to access the response, because that response with the Access-Control-Allow-Originresponse header is what the browser sees.

然后浏览器允许前端代码访问响应，因为带有Access-Control-Allow-Origin响应头的响应是浏览器看到的。

You can easily run your own proxy using code from https://github.com/Rob--W/cors-anywhere/.
You can also easily deploy your own proxy to Heroku in literally just 2-3 minutes, with 5 commands:

您可以使用https://github.com/Rob--W/cors-anywhere/ 中的代码轻松运行您自己的代理。
您还可以使用 5 个命令在 2-3 分钟内轻松将自己的代理部署到 Heroku：

git clone https://github.com/Rob--W/cors-anywhere.git
cd cors-anywhere/
npm install
heroku create
git push heroku master

After running those commands, you'll end up with your own CORS Anywhere server running at, e.g., https://cryptic-headland-94862.herokuapp.com/. So then rather than prefixing your request URL with https://cors-anywhere.herokuapp.com, prefix it instead with the URL for your own instance; e.g., https://cryptic-headland-94862.herokuapp.com/https://example.com.

运行这些命令后，您最终将拥有自己的 CORS Anywhere 服务器，例如在https://cryptic-headland-94862.herokuapp.com/ 上运行。因此，与其在您的请求 URL 前面加上https://cors-anywhere.herokuapp.com前缀，不如在它前面加上您自己实例的 URL；例如，https: //cryptic-headland-94862.herokuapp.com/https: //example.com。

So if when you go to try to use https://cors-anywhere.herokuapp.com, you find it's down(which it sometimes will be), then consider getting a Heroku account (if you don't already) and take 2 or 3 minutes to do the steps above to deploy your own CORS Anywhere server on Heroku.

因此，如果当您尝试使用 https://cors-anywhere.herokuapp.com 时，您发现它已关闭（有时会如此），请考虑获取一个 Heroku 帐户（如果您还没有）并使用 2或 3 分钟执行上述步骤，在 Heroku 上部署您自己的 CORS Anywhere 服务器。

Regardless, whether you run your own or use https://cors-anywhere.herokuapp.comor other open proxy, this solution works even if the request is one that triggers browsers to do a CORS preflight OPTIONSrequest—because in that case, the proxy also sends back the Access-Control-Allow-Headersand Access-Control-Allow-Methodsheaders needed to make the preflight successful.

无论如何，无论您运行自己的代理还是使用https://cors-anywhere.herokuapp.com或其他开放代理，即使请求是触发浏览器执行 CORS 预检OPTIONS请求的请求，该解决方案也能正常工作，因为在这种情况下，代理还发回使预检成功所需的Access-Control-Allow-Headers和Access-Control-Allow-Methods标头。

How to avoid the CORS preflight

如何避免 CORS 预检

The code in the question triggers a CORS preflight—since it sends an Authorizationheader.

问题中的代码会触发 CORS 预检——因为它发送了一个Authorization标头。

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests

Even without that, the Content-Type: application/jsonheader would also trigger the preflight.

即使没有，Content-Type: application/json标题也会触发预检。

What “preflight” means: before the browser tries the POSTin the code in the question, it'll first send an OPTIONSrequest to the server — to determine if the server is opting-in to receiving a cross-origin POSTthat includes the Authorizationand Content-Type: application/jsonheaders.

“预检”的意思是：在浏览器尝试输入问题POST中的代码之前，它会首先向OPTIONS服务器发送请求——以确定服务器是否选择接收POST包含Authorization和Content-Type: application/json标头的跨域。

It works pretty well with a small curl script - I get my data.

它与一个小的 curl 脚本配合得很好 - 我得到了我的数据。

To properly test with curl, you must emulate the preflight OPTIONSrequest the browser sends:

要正确测试curl，您必须模拟OPTIONS浏览器发送的预检请求：

curl -i -X OPTIONS -H "Origin: http://127.0.0.1:3000" \
    -H 'Access-Control-Request-Method: POST' \
    -H 'Access-Control-Request-Headers: Content-Type, Authorization' \
    "https://the.sign_in.url"

…with https://the.sign_in.urlreplaced by whatever your actual sign_inURL is.

...https://the.sign_in.url替换为您的实际sign_inURL。

The response the browser needs to see from that OPTIONSrequest must include headers like this:

浏览器需要从该OPTIONS请求中看到的响应必须包含如下标题：

Access-Control-Allow-Origin:  http://127.0.0.1:3000
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type, Authorization

If the OPTIONSresponse doesn't include those headers, then the browser will stop right there and never even attempt to send the POSTrequest. Also, the HTTP status code for the response must be a 2xx—typically 200 or 204. If it's any other status code, the browser will stop right there.

如果OPTIONS响应不包含这些标头，那么浏览器将在那里停止，甚至不会尝试发送POST请求。此外，响应的 HTTP 状态代码必须是 2xx——通常是 200 或 204。如果是任何其他状态代码，浏览器将在那里停止。

The server in the question is responding to the OPTIONSrequest with a 501 status code, which apparently means it's trying to indicate it doesn't implement support for OPTIONSrequests. Other servers typically respond with a 405 “Method not allowed” status code in this case.

问题中的服务器正在OPTIONS使用 501 状态代码响应请求，这显然意味着它试图表明它没有实现对OPTIONS请求的支持。在这种情况下，其他服务器通常以 405“不允许方法”状态代码响应。

So you're never going to be able to make POSTrequests directly to that server from your frontend JavaScript code if the server responds to that OPTIONSrequest with a 405 or 501 or anything other than a 200 or 204 or if doesn't respond with those necessary response headers.

因此POST，如果服务器OPTIONS使用 405 或 501 或 200 或 204 以外的任何内容响应该请求，或者没有响应那些必要的请求，则您永远无法从前端 JavaScript 代码直接向该服务器发出请求响应头。

The way to avoid triggering a preflight for the case in the question would be:

避免为问题中的案例触发预检的方法是：

if the server didn't require an Authorizationrequest header but instead (for example) relied on authentication data embedded in the body of the POSTrequest or as a query parameter
if the server didn't require the POSTbody to have a Content-Type: application/jsonmedia type but instead accepted the POSTbody as application/x-www-form-urlencodedwith a parameter named json(or whatever) whose value is the JSON data

如果服务器不需要Authorization请求标头，而是（例如）依赖嵌入在POST请求正文中的身份验证数据或作为查询参数
如果服务器不要求POST主体具有Content-Type: application/json媒体类型，而是接受POST主体作为application/x-www-form-urlencoded参数命名json（或其他），其值为 JSON 数据

How to fix “Access-Control-Allow-Origin header must not be the wildcard”problems

如何解决“Access-Control-Allow-Origin 标头不能是通配符”问题

I am getting another error message:
The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. Origin 'http://127.0.0.1:3000' is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

我收到另一条错误消息：
当请求的凭据模式为“包含”时，响应中“Access-Control-Allow-Origin”标头的值不得为通配符“*”。因此不允许访问源“ http://127.0.0.1:3000”。XMLHttpRequest 发起的请求的凭证模式由 withCredentials 属性控制。

For a request that includes credentials, browsers won't let your frontend JavaScript code access the response if the value of the Access-Control-Allow-Originresponse header is *. Instead the value in that case must exactly match your frontend code's origin, http://127.0.0.1:3000.

对于包含凭据的请求，如果Access-Control-Allow-Origin响应标头的值为，则浏览器不会让您的前端 JavaScript 代码访问响应*。相反，这种情况下的值必须与您的前端代码的来源完全匹配http://127.0.0.1:3000。

See Credentialed requests and wildcardsin the MDN HTTP access control (CORS) article.

请参阅MDN HTTP 访问控制 (CORS) 文章中的凭据请求和通配符。

If you control the server you're sending the request to, then a common way to deal with this case is to configure the server to take the value of the Originrequest header, and echo/reflect that back into the value of the Access-Control-Allow-Originresponse header. For example, with nginx:

如果您控制将请求发送到的服务器，那么处理这种情况的常用方法是配置服务器以获取Origin请求标头的值，并将其回显/反映回Access-Control-Allow-Origin响应标头的值。例如，使用 nginx：

add_header Access-Control-Allow-Origin $http_origin

But that's just one example; other (web) server systems provide similar ways to echo origin values.

但这只是一个例子；其他（网络）服务器系统提供类似的方法来回显原始值。

I am using Chrome. I also tried using that Chrome CORS Plugin

我正在使用 Chrome。我也试过使用那个 Chrome CORS 插件

That Chrome CORS plugin apparently just simplemindedly injects an Access-Control-Allow-Origin: *header into the response the browser sees. If the plugin were smarter, what it would be doing is setting the value of that fake Access-Control-Allow-Originresponse header to the actual origin of your frontend JavaScript code, http://127.0.0.1:3000.

Chrome CORS 插件显然只是简单地将Access-Control-Allow-Origin: *标头注入浏览器看到的响应中。如果插件更智能，它会做的是将假Access-Control-Allow-Origin响应标头的值设置为前端 JavaScript 代码的实际来源，http://127.0.0.1:3000.

So avoid using that plugin, even for testing. It's just a distraction. If you want to test what responses you get from the server with no browser filtering them, you're better off using curl -Has above.

所以避免使用该插件，即使是为了测试。这只是一种分心。如果您想测试您从服务器获得的响应，而没有浏览器过滤它们，最好使用curl -H上述方法。

As far as the frontend JavaScript code for the fetch(…)request in the question:

至于fetch(…)问题中请求的前端 JavaScript 代码：

headers.append('Access-Control-Allow-Origin', 'http://localhost:3000');
headers.append('Access-Control-Allow-Credentials', 'true');

Remove those lines. The Access-Control-Allow-*headers are responseheaders. You never want to send them in a request. The only effect that'll have is to trigger a browser to do a preflight.

删除这些行。该Access-Control-Allow-*头是响应头。您永远不想在请求中发送它们。唯一的效果是触发浏览器进行预检。

Answer 2

回答by Rakesh

This error occurs when the client URL and server URL don't match, including the port number. In this case you need to enable your service for CORS which is cross origin resource sharing.

当客户端 URL 和服务器 URL 不匹配（包括端口号）时，会发生此错误。在这种情况下，您需要为跨源资源共享的 CORS 启用您的服务。

If you are hosting a Spring REST service then you can find it in the blog post CORS support in Spring Framework.

如果您正在托管 Spring REST 服务，那么您可以在博客文章Spring Framework 中的 CORS 支持中找到它。

If you are hosting a service using a Node.js server then

如果您使用 Node.js 服务器托管服务，那么

Stop the Node.js server.
npm install cors --save

Add following lines to your server.js

var cors = require('cors')

app.use(cors()) // Use this after the variable declaration

停止 Node.js 服务器。
npm install cors --save

将以下行添加到您的 server.js

var cors = require('cors')

app.use(cors()) // Use this after the variable declaration

Answer 3

回答by Lex Soft

The problem arose because you added the following code as requestheader in your front-end :

出现问题是因为您在前端添加了以下代码作为请求标头：

headers.append('Access-Control-Allow-Origin', 'http://localhost:3000');
headers.append('Access-Control-Allow-Credentials', 'true');

Those headers belong to response, not request. So removethem, including the line :

这些标头属于response，而不是 request 。所以删除它们，包括行：

headers.append('GET', 'POST', 'OPTIONS');

Your request had 'Content-Type: application/json', hence triggered what is called CORS preflight. This caused the browser sent the request with OPTIONS method. See CORS preflightfor detailed information.
Therefore in your back-end, you have to handle this preflighted request by returning the response headers which include :

您的请求具有“内容类型：应用程序/json”，因此触发了所谓的 CORS 预检。这导致浏览器使用 OPTIONS 方法发送请求。有关详细信息，请参阅CORS 预检。
因此，在您的后端，您必须通过返回响应标头来处理此预检请求，其中包括：

Access-Control-Allow-Origin : http://localhost:3000
Access-Control-Allow-Credentials : true
Access-Control-Allow-Methods : GET, POST, OPTIONS
Access-Control-Allow-Headers : Origin, Content-Type, Accept

Of course, the actual syntax depends on the programming language you use for your back-end.

当然，实际语法取决于您用于后端的编程语言。

In your front-end, it should be like so :

在您的前端，它应该是这样的：

function performSignIn() {
    let headers = new Headers();

    headers.append('Content-Type', 'application/json');
    headers.append('Accept', 'application/json');
    headers.append('Authorization', 'Basic ' + base64.encode(username + ":" +  password));
    headers.append('Origin','http://localhost:3000');

    fetch(sign_in, {
        mode: 'cors',
        credentials: 'include',
        method: 'POST',
        headers: headers
    })
    .then(response => response.json())
    .then(json => console.log(json))
    .catch(error => console.log('Authorization failed : ' + error.message));
}

Answer 4

回答by Harrison O

In my case,I use the below solution

就我而言，我使用以下解决方案

Front-end or Angular

前端或角度

post(
    this.serverUrl, dataObjToPost,
    {
      headers: new HttpHeaders({
           'Content-Type':  'application/json',
         })
    }
)

back-end (I use php)

后端（我使用php）

header("Access-Control-Allow-Origin: http://localhost:4200");
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
header("Access-Control-Allow-Headers: Content-Type, Authorization");

$postdata = file_get_contents("php://input");
$request = json_decode($postdata);
print_r($request);

Answer 5

回答by Yair Levy

Just my two cents... regarding How to use a CORS proxy to get around “No Access-Control-Allow-Originheader” problems

只是我的两分钱......关于如何使用 CORS 代理解决“无Access-Control-Allow-Origin标题”问题

For those of you working with php at the backend, deploying a "CORS proxy" is as simple as:

对于那些在后端使用 php 的人来说，部署“CORS 代理”非常简单：

create a file named 'no-cors.php' with the following content:
$URL = $_GET['url']; echo json_encode(file_get_contents($URL)); die();
on your front end, do something like:
fetch('https://example.com/no-cors.php' + '?url=' + url) .then(response=>{*/Handle Response/*})

创建一个名为“no-cors.php”的文件，内容如下：
$URL = $_GET['url']; echo json_encode(file_get_contents($URL)); die();
在您的前端，执行以下操作：
fetch('https://example.com/no-cors.php' + '?url=' + url) .then(response=>{*/Handle Response/*})

Answer 6

回答by Nalan Madheswaran

Remove this:

删除这个：

credentials: 'include',

Answer 7

回答by hoogw

Using dataType: 'jsonp'worked for me.

使用dataType: 'jsonp'对我有用。

   async function get_ajax_data(){
       var _reprojected_lat_lng = await $.ajax({
                                type: 'GET',
                                dataType: 'jsonp',
                                data: {},
                                url: _reprojection_url,
                                error: function (jqXHR, textStatus, errorThrown) {
                                    console.log(jqXHR)
                                },
                                success: function (data) {
                                    console.log(data);

                                    // note: data is already json type, you
                                    //       just specify dataType: jsonp
                                    return data;
                                }
                            });


 } // function

Answer 8

回答by Jorge Dominguez

I was working with Spring REST, and I solved it adding the AllowedMethods into the WebMvcConfigurer.

我正在使用 Spring REST，我解决了将 AllowedMethods 添加到 WebMvcConfigurer 中的问题。

@Value( "${app.allow.origins}" )
    private String allowOrigins;    
@Bean
public WebMvcConfigurer corsConfigurer() {
            System.out.println("allow origin: "+allowOrigins);
            return new WebMvcConfigurerAdapter() {
                @Override
                public void addCorsMappings(CorsRegistry registry) {
                    registry.addMapping("/**")
                    //.allowedOrigins("http://localhost")
                    .allowedOrigins(allowOrigins)
                    .allowedMethods("PUT", "DELETE","GET", "POST");
                }
            };
        }

Answer 9

回答by Juneho Nam

In my case, web server prevented "OPTIONS" method

就我而言，网络服务器阻止了“OPTIONS”方法

Check your web server for the options method

检查您的网络服务器的选项方法

apache : https://www-01.ibm.com/support/docview.wss?uid=ibm10735209
webtier : 4.4.6 Disabling the Options Method https://docs.oracle.com/cd/E23943_01/web.1111/e10144/getstart.htm#HSADM174
nginx : https://medium.com/@hariomvashisth/cors-on-nginx-be38dd0e19df

阿帕奇：https: //www-01.ibm.com/support/docview.wss?uid =ibm10735209
webtier：4.4.6 禁用选项方法https://docs.oracle.com/cd/E23943_01/web.1111/e10144/getstart.htm#HSADM174
nginx：https: //medium.com/@hariomvashisth/cors-on-nginx-be38dd0e19df

I'm using "webtier"
/www/webtier/domains/[domainname]/config/fmwconfig/components/OHS/VCWeb1/httpd.conf

我正在使用“网络层”
/www/webtier/domains/[域名]/config/fmwconfig/components/OHS/VCWeb1/httpd.conf

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{REQUEST_METHOD} ^OPTIONS
  RewriteRule .* . [F]
</IfModule>

change to

改成

<IfModule mod_rewrite.c>
  RewriteEngine off
  RewriteCond %{REQUEST_METHOD} ^OPTIONS
  RewriteRule .* . [F]
</IfModule>

Answer 10

回答by ugurrrrr

I was getting this error on my local. I ran Visual Studio as an administrator and it resolved.

我在本地收到此错误。我以管理员身份运行 Visual Studio 并解决了。

Javascript 请求的资源上不存在“Access-Control-Allow-Origin”标头——尝试从 REST API 获取数据时

提问by daniel.lozynski

回答by sideshowbarker

回答by Rakesh

回答by Lex Soft

回答by Harrison O

回答by Yair Levy

回答by Nalan Madheswaran

回答by hoogw

回答by Jorge Dominguez

回答by Juneho Nam

回答by ugurrrrr

相关推荐

最近更新

标签

Javascript 请求的资源上不存在“Access-Control-Allow-Origin”标头——尝试从 REST API 获取数据时

提问by daniel.lozynski

回答by sideshowbarker

回答by Rakesh

回答by Lex Soft

回答by Harrison O

回答by Yair Levy

回答by Nalan Madheswaran

回答by hoogw

回答by Jorge Dominguez

回答by Juneho Nam

回答by ugurrrrr

相关推荐

Javascript 如何在支持触摸的浏览器中通过触摸模拟悬停？

Javascript 如何在 React 组件中导入图像 (.svg, .png )

Javascript 使用 React JS 的右键菜单

Javascript 清除文本 onclick - 文本字段

相关推荐

最近更新

标签