No data appears when connecting from dyanamic IP. Only CSS structure stays.

[ArandomB]

My ISP only provides dynamic IP and none of the pages have any data entries. No heroes, No kills, no item, no match id nothing. Only page table borders are displayed. API call shows full data however it doesn't appear on the webpage itself. Problem appears in all browsers. Webpage only appears properly when I use a proxy/VPN with a static IP. Not an issue with adblock as results are same. Never had any problem with previous yasp/opendota on this.

• Windows 8:
• 1680x1050:
• All browsers: Chrome Firefox Opera:
• http://imgur.com/a/rIAg0 :

[howardchung]

Can you verify if this endpoint returns data: https://api.opendota.com/api

If it doesn't work, can you try the http version: http://api.opendota.com/api

[ArandomB]

My original text didn't come through earlier because of comment lines. Please read it now. Both of the API calls shows data, 1st one required captcha. .

[howardchung]

This might be related to #435 . Can you check your browser console for errors when you try to load a page? Are you using http or https when loading the UI?

[ArandomB]

I get this in console:

Failed to load resource: the server responded with a status of 403 () http://api.opendota.com/api/matches/2775840834 Failed to load resource: the server responded with a status of 403 (Forbidden) 2775840834:1 Fetch API cannot load http://api.opendota.com/api/matches/2775840834. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.opendota.com' is therefore not allowed access. The response had HTTP status code 403. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled. http://api.opendota.com/api/players/117886621 Failed to load resource: the server responded with a status of 403 (Forbidden) 2775840834:1 Fetch API cannot load http://api.opendota.com/api/players/117886621. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.opendota.com' is therefore not allowed access. The response had HTTP status code 403. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled. http://www.opendota.com/matches/2775840834 Failed to load resource: the server responded with a status of 404 (Not Found) https://cdn.myfontastic.com/ajkCKZcprWV8fCCd7UykoN/icons.css Failed to load resource: the server responded with a status of 403 ()

My browsers defaults to https but tried it with http and still same.

[howardchung]

This line determines what header to send back.

https://github.com/odota/core/blob/master/routes/api.js#L10

Can you use the Network tab to inspect the outgoing request and see what the Origin header is set to?

My guess is that it's something other than www.opendota.com so that's what the server sends back.

[ArandomB]

I opened the network tab on a match page, not sure which entry I should be looking for. Can you tell me a subtab or any keywords I can enter into the filter box. Looked for "origin", "header", "access". Nothing gave a result

[howardchung]

Try "metadata", then click on it. There should be a sub-tab called Headers. You may need to refresh the page with the console open.

[ArandomB]

For metadata header:

General: Request URL:http://api.opendota.com/api/metadata Request Method:GET Status Code:304 Not Modified Remote Address:104.27.128.214:80

Response Headers view source Access-Control-Allow-Credentials:true Access-Control-Allow-Headers:origin, content-type, accept Access-Control-Allow-Origin:http://www.opendota.com CF-RAY:3019a09117672fbd-MAA Connection:keep-alive Date:Mon, 14 Nov 2016 10:02:20 GMT ETag:W/"56-bBwDJqGL2f/3Ipa5zmMaHg" Server:cloudflare-nginx X-Powered-By:Express

Request Headers view source Accept:/ Accept-Encoding:gzip, deflate, sdch Accept-Language:en-US,en;q=0.8 Connection:keep-alive Cookie:__cfduid=df54903cfb05539fe716fbf95133dfa1c1476741090; session=eyJwYXNzcG9ydCI6eyJ1c2VyIjoxMTc4ODY2MjF9fQ==; session.sig=XRfj5a7zKdChX3bQ_s0W449eub8; cf_clearance=75ea29a1a8d905660fe75299ef3943cca99b5c7b-1479117094-1800; _ga=GA1.2.1396525433.1478516037; _gat=1 DNT:1 Host:api.opendota.com If-None-Match:W/"56-bBwDJqGL2f/3Ipa5zmMaHg" Origin:http://www.opendota.com Referer:http://www.opendota.com/matches/2764382496 User-Agent:Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36

/end

Also, under the response tab it shows only 1 line: {"user":{"account_id":117886621},"banner":null,"cheese":{"cheese":"197","goal":"200"}}

Btw, the entry metadata shows green. Two entries near it (one has match id, another hero id) shows red. This is the header of the entry with matchid:

`General:`` Request URL:http://api.opendota.com/api/matches/2764382496 Request Method:GET Status Code:403 Forbidden Remote Address:104.27.128.214:80

Response Headers view source Cache-Control:max-age=2 CF-RAY:3019a09126d72fe1-MAA Connection:close Content-Encoding:gzip Content-Type:text/html; charset=UTF-8 Date:Mon, 14 Nov 2016 10:02:19 GMT Expires:Mon, 14 Nov 2016 10:02:21 GMT Server:cloudflare-nginx Set-Cookie:__cfduid=da9d8a9f94f4b86bdfe137117e049333c1479117739; expires=Tue, 14-Nov-17 10:02:19 GMT; path=/; domain=.opendota.com; HttpOnly Transfer-Encoding:chunked X-Frame-Options:SAMEORIGIN

Request Headers view source Accept:/ Accept-Encoding:gzip, deflate, sdch Accept-Language:en-US,en;q=0.8 Connection:keep-alive DNT:1 Host:api.opendota.com Origin:http://www.opendota.com Referer:http://www.opendota.com/matches/2764382496 User-Agent:Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36 Name

[howardchung]

What is the body of the match request (response tab?)

[ArandomB]

Says no response.

[howardchung]

I swapped to using the cors npm package. Can you check if it's fixed in a few minutes?

[howardchung]

Does this problem affect player pages?

[howardchung]

@ArandomB , can you confirm:

• Is the problem fixed now?
• If not, are only match pages broken or both match and player pages?

[ArandomB]

Sorry for the delay. No the problem still is same in matches. Player profiles are a bit buggy but all data entries appear there.

[howardchung]

Hmm, interesting, it sounds like passing credentials: true (sending cookies with request) makes it work then. I'll change #491 to instead pass credentials rather than remove them.

[howardchung]

Can you check again? I'm using {credentials: 'include'} on all requests now.

[ArandomB]

Profiles are now working perfectly. Even steam login is working. Matches still come up empty.

[ArandomB]

It seems some matches are working, while others not.

Edit: Entries with error on the network tab are:

icons.css ttj mixpanel-2-latest.min.js

Edit2: The headers of the last 2 says provisional headers are being used. icons.css header shows:

General Request URL:https://cdn.myfontastic.com/ajkCKZcprWV8fCCd7UykoN/icons.css Request Method:GET Status Code:403 Remote Address:104.25.95.111:443 Response Headers cache-control:max-age=2 cf-ray:30415095aa5c329b-HKG content-encoding:gzip content-type:text/html; charset=UTF-8 date:Sat, 19 Nov 2016 05:38:14 GMT expires:Sat, 19 Nov 2016 05:38:16 GMT server:cloudflare-nginx status:403 x-frame-options:SAMEORIGIN Request Headers :authority:cdn.myfontastic.com :method:GET :path:/ajkCKZcprWV8fCCd7UykoN/icons.css :scheme:https accept:text/css,/;q=0.1 accept-encoding:gzip, deflate, sdch, br accept-language:en-US,en;q=0.8 cookie:__cfduid=ddf1a4dd0e35747e2930673022eb940961477042129 dnt:1 referer:https://www.stanza.co/@dota2?embed=true&banner=true&site=opendota user-agent:Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36

Edit 3: It seems the red entries appear in both working match pages and empty ones.

[howardchung]

Yeah, that should not affect the match page loading. Is there an entry labeled with the match_id, and request URL should be https://api.opendota.com/api/matches/{match_id}?

[howardchung]

With https://github.com/odota/core/pull/1367 I am using a wildcard CORS header for all endpoints except /metadata. (/metadata returns user login state, so it needs to accept credentials, which means it needs to return a single origin, which means it needs to read the origin header from request). I think that should solve the issue. Check again in a couple of hours, if @ArandomB confirms it's fixed I'll close this.

[ArandomB]

Not working yet. I guess only a few users are facing this so maybe not worth to fix it. My ISP uses dynamic IPs, blocks listening ports and probably a lot more things which is why I'm facing this.

This is what I'm getting now.

I won't be able to reply much this week so might as well close this thread.

[howardchung]

Eh, I'd still like to get to the bottom of this. I can wait--can you provide the header dump for the match request? It'll be the red one starting with 266

[howardchung]

Actually the 403 is the same as what you posted before. When you have time, could you share the response body of the request?

[ArandomB]

My ISP introduced a login portal(had to use connect option before) and this fixed itself. I'm not facing this or any captcha issues anymore. Couldn't be of help sorry. Can I ask why profile stopped working after I reported the issue? Only matches were bugged when I first reported here but later even profiles stopped working. Maybe the solution lies there.

[howardchung]

It seems like passing {credentials: 'include'} makes it work. This is basically sending the login cookie along with the request. I took it out because it shouldn't be necessary on anything except for the request that gets login state, but it seems like for some reason it solves whatever issue you were having.