I'm making a facebook login for a client. But i keep getting the error:
the given url is not allowed by the application configuration
This is not new to me and I know what the error means and how to correct it. But this time i'm really puzzled, as I have tried every possible solution and still no result.
I'm using the newest Facebook PHP SDK (v.3.2.2) and integrated it into a codeigniter (v.2.0) project i received from my client. I have tried every possible website url. With and without http, with and without www and with and without slashes.
Please write if you need more information.
DOCUMENTATION :
The facebook settings right now :
App name: myDomain.com
App Namespace : myDomain.com
Sandbox Mode : off
Allowed domains : myDomain.com (Also tried www.myDomain.com just to test)
Website with Facebook Login : http:// www.myDomain.com/
THE HTTP REQUEST (I highlighted the most important) :
GET /dialog/oauth?client_id=416398375038503&redirect_uri=http%3A%2F%2Fwww.myDomain.com%2F&state=c7fcaa638bb00e28177b2551ab285199&scope=email HTTP/1.1
Host: www.facebook.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
Referer: **http://www.myDomain.com/**
Accept-Encoding: gzip,deflate,sdch
Accept-Language: da-DK,da;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: locale=da_DK; datr=c352UWXk3ZNnDRb9vF_flCKf; lu=ThIiiPnfHJO6URgttq6n991g; p=30; presence=EM371808349EuserFA21015531322A2EstateFDsb2F1371646911100Et2F_5b_5dElm2FnullEuct2F1371756338BEtrFnullEtwF2809378943EatF1371808247422EwmlFDfolderFA2inboxA2Ethread_5fidFA2user_3a1275290355A2CG371808349901CEchFDp_5f1015531322F9CC; sub=8192; act=1371810189642%2F3; c_user=1015531322; csm=2; fr=0Q2dUDn4VqDw2NwPO.AWUeSLjGpJH-4uKuONHiGbL-jYE.BRdn55.S8.AWVTnqQG; s=Aa7pqsZ0XxblFusE.BRwH3a; xs=1%3A7IUHTcAXzyAQdg%3A2%3A1371569626; wd=1363x712
Query String Parametersview sourceview URL encoded
client_id:416398375038503
redirect_uri: **http://www.myDomain.com/**
state:c7fcaa638bb00e28177b2551ab285199
scope:email
Want to improve this post? Add citations from reputable sources by editing the post. Posts with unsourced content may be edited or deleted.
Try once by removing the Allowed domains setting
Related
First time asking a question here. I'm a beginner at this, but i'm truly stumped at the problem i'm facing.
Browsers in use:
Safari and Firefox (both on Mac OS Sierra)
Firefox (Linux - Ubuntu 16.04.2)
I am registered as an Uber Developer and have registered an App in the Dashboard. I'm only using the Server Token for authentication at the moment. In the Dashboard, I have set the following entries in the "Authorizations" tab of the App for CORS (Optional URI for CORS Support):
http://localhost:8000 <-- web server in my PC
https://subdomain.mydomain.com <--- remote web server
A few months ago i created a web app using HTML, CSS and JS (with Jquery v2.2.4) to play around with the Ride Estimates API and was able to get it to report data for many locations in my area successfully. Somehow it no longer works. I'm trying to fix that and improve the functionality. However, i just can't get past the initial query to the API because of CORS issues that were not existent before.
My API URL is:
https://api.uber.com/v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********}
When i paste that in the address bar of the browser i get valid JSON:
{"prices":[{"localized_display_name":"uberX","distance":1.58,"display_name":"uberX","product_id":"811c3224-5554-4d29-98ae-c4366882011f","high_estimate":3,"surge_multiplier":1.0,"minimum":2,"low_estimate":2,"duration":420,"estimate":"2-3\u00a0$","currency_code":"USD"},{"localized_display_name":"X English","distance":1.58,"display_name":"X English","product_id":"8fe2c122-a4f0-43cc-97e0-ca5ef8b57fbc","high_estimate":4,"surge_multiplier":1.0,"minimum":3,"low_estimate":3,"duration":420,"estimate":"3-4\u00a0$","currency_code":"USD"},{"localized_display_name":"uberXL","distance":1.58,"display_name":"uberXL","product_id":"eb454d82-dcef-4d56-97ca-04cb11844ff2","high_estimate":4,"surge_multiplier":1.0,"minimum":3,"low_estimate":3,"duration":420,"estimate":"3-4\u00a0$","currency_code":"USD"},{"localized_display_name":"Uber Black","distance":1.58,"display_name":"Uber Black","product_id":"ba49000c-3b04-4f54-8d50-f7ae0e20e867","high_estimate":6,"surge_multiplier":1.0,"minimum":4,"low_estimate":4,"duration":420,"estimate":"4-6\u00a0$","currency_code":"USD"},{"localized_display_name":"Uber SUV","distance":1.58,"display_name":"Uber SUV","product_id":"65aaf0c2-655a-437d-bf72-5d935cf95ec9","high_estimate":7,"surge_multiplier":1.0,"minimum":5,"low_estimate":5,"duration":420,"estimate":"5-7\u00a0$","currency_code":"USD"}]}
I then proceed to set up JS (w/ JQuery) code in webpage...
var url = "https://api.uber.com/v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********}";
$.getJSON(url, function(result){
console.log(result);
});
Uploading the HTML and JS to my remote web server and then loading the webpage in any of my browsers yields a 200 status from Uber API. However, the console log shows CORS blocking my request (PROBLEM #1):
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.uber.com/v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********}. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Then, in the Inspector view of both Mac Browsers, under the Network / Resources areas, i see the 200 Status message from the GET request. However, along with the Response message (PROBLEM #2):
SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data
The Request Headers are:
GET /v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********} HTTP/1.1
Host: api.uber.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://subdomain.domain.com/Uber/index.html
Origin: https://subdomain.domain.com
Connection: keep-alive
The Response Headers are:
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 19 Mar 2017 22:26:31 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Content-Geo-System: wgs-84
Content-Language: en
X-Rate-Limit-Limit: 2000
X-Rate-Limit-Remaining: 1998
X-Rate-Limit-Reset: 1489964400
X-Uber-App: uberex-nonsandbox, optimus, migrator-uberex-optimus
Strict-Transport-Security: max-age=604800
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Encoding: gzip
In Firefox for Linux i sometimes don't get the Syntax Error; i always seem to get it on the Mac Browsers. In Linux, when i do get that error, then clicking on the "Edit and Resend" Headers button (resending the Headers but without really editing the Headers), the Syntax Error disappears and the Response text actually shows the Uber API Object that is supposed to be there... but i still get the CORS Blocked message on the Console Log. I really don't understand why this is, but it seems contradictory. In the end, i am unable to get to use the API data that, using the same method months ago, i could get for several dozens of locations.
I have looked for answers in similar questions but so far have found none that apply to my case. Any help will be greatly appreciated. Getting really frustrated... really stuck here.
This issue was caused by the API not including the header correctly. This issue is resolved and the api is now working as expected. Also, the allow origin header will only be returned in a response if an origin is specified in the request.
Context and troubles
I'm currently building a web application on top of ezPlatform & Symfony.
My goal is now to request this app from an external website using a JS client (using the JS REST client of ezplatform : CAPI.js)
I tested my script localy (on the app itself = same domain) and everything is fine : I can GET and POST data.
But testing this script on an external webiste (CORS requests) didn't work. I am stuck with 2 differents problems :
Server side : The response headers do not contains the Access-Control-Allowed-Methods
Client side : No session cookies are given within a request
Details
Problem 1 : No header "allow_methods"
On chrome I always have this error :
XMLHttpRequest cannot load http://api.ezplatform.lan/api/ezp/v2/user/sessions. Response for preflight has invalid HTTP status code 405
Note that, on the server side, nelmio_cors bundle is used to configures the headers. The configs :
nelmio_cors:
paths:
'^/api/ezp/v2/':
max_age: 3600
allow_credentials: true
allow_origin: ['*']
allow_methods: ['POST', 'PUT', 'GET', 'DELETE', 'OPTIONS']
expose_headers: []
And now, here are the details of a failing preflight request :
GENERAL
Request URL:http://api.ezplatform.lan/api/ezp/v2/user/sessions
Request Method:OPTIONS
Status Code:405 Method Not Allowed
Remote Address:192.168.1.82:80
REPONSE HEADERS
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:authorization, accept, content-type, x-csrf-token, destination, x-siteaccess
Access-Control-Allow-Origin:http://www.externalsite.lan
Access-Control-Max-Age:3600
Cache-Control:private
Connection:Keep-Alive
Content-Length:0
Content-Type:text/html; charset=UTF-8
Date:Tue, 13 Dec 2016 15:24:44 GMT
Keep-Alive:timeout=5, max=99
Server:Apache/2.4.23 (Ubuntu)
Vary:X-User-Hash
REQUEST HEADERS
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Access-Control-Request-Headers:content-type
Access-Control-Request-Method:POST
Cache-Control:no-cache
Connection:keep-alive
Host:api.ezplatform.lan
Origin:http://www.externalsite.lan
Pragma:no-cache
Referer:http://www.externalsite.lan/
User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
In the "response headers", there is no Access-Control-Allow-Methods despite of the nelmio_cors configs.
Digging inside the nelmio_cors code I realized that the "allow_methods" config is retrieved but is then overwritten by something else, and here it becomes obscur to me.
This old ezpublish bug maybe give me a clue about the situation : the ezPublishRestBundle does not seems to find any "allowed method", and somehow overwrite the nelmio_cors config.
In the Resprovider.php file, if I force the methods getAllowedMethods to return this :
return ["POST", "PUT", "GET", "DELETE", "OPTIONS"]; then I have no more 405 error but a very different problem (explained right after this)
Problem 2 : no session cookies allowed
With my previous wonderful hack, I can now get a little bit further : my request are allowed but some of them are still failing.
I noticed that no session cookie is passed inside the requests (which is the normal behaviour testing on the same domain).
This times it seems to come from the CAPI.js file : the XmlHttpRequest object never has the property withCredentials to true.
If I add this code XHR.withCredentials = true; in CAPI.js before the request is send, then it seems to be fine.
Conclusion
I really wonder if the ez Platform rest client has been designed to be used for cross domain, but it would be very surprising if not.
So I must do something wrong, and if someone can explain me what, I would be extemely grateful :)
I am receiving a paypal 502 bad gateway response when I run my site on my chrome browser.
However, the same request from an incognito window seems to work fine and it also works in firefox on the same machine.
I have cleared my cache so I am concerned that there might be something wrong with the request logic; but my developers cannot reproduce this problem either. I don't want to find out later that some customers are not able to get the paypal payment screen so I'm hoping to track down the cause of this.
Here's the GET request we make:
Request URL:https://www.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=EC-57N00510UU258144B&useraction=commit
And the request headers:
Request Headers
view source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:ectoken=EC-49T82408DT104494D; cookie_check=yes; Apache=10.16.0.11.1431638973833393; upct=40; U4L8zB-ydunrQGaacZ4QhTcWTQO=nlhUU2xhsjSHwYqUWd-TTY_8W2pczcnQ8IMn1-jAtlxnKswogZfSLaZliKxvbaR35sjdx0; VmyeHxjTc5yWtKApgk8-f2SgjEC=XEw7Wsf3s6dovD5b482-er8pyuUZZZzmYOzngmadzSx3vvu5KJDDcUykM3fLeC-IR-Lqtl3KFRACRpIhl7blvnEK1EW; tkkUEuFUb_mahcIlS49RY52hwu8=Cd2Drxd3-HmviU-mUNppGeUftri_7B-NakEP09nDXyD4oeH81HlJJF8G8pmQ-5lefaTzjzdsEC5G8g6VLL7rKgsFdv7P3awp_pMYMG; eightBallUser=false; ppip_signup=; g2bQrGu--VIan06DHlaPDvMaBlO=yx3W0TOYs53uA61kSB81QzzTe_ktz3ucFuAJAylmm92x6jJFnwHGhzkg3aDzgm7cXOKwobYm83pA6gie3qB5Pg8eyq2vKOi9BWZ1Pi_haU5Ji17z-PK-i3RVgj1-2bPVPYYY0C_96LIpgFqzgVcFw_4gPnamJjVZZbSK3po3FujrLQCiN6_BYCbI5ls9bukVtgvYdAR0ueEeN3TVj_dzIIcBxndaO3gWSXJVa_4x7JV91Ieq0aCLh4MT-OcCy4WXCuOMq4WIoDNFS0MqhsWkMWEjoBbb8YKZ1lBdr-bpyPv8k8q7771SsQNeakm6YcllxooQOwrsQdDDF0bLsnYr56hVUXGGq-wj6WaUy1Qncc0axFEdWaTzTzeTZDElLgq5TqoKg0UOKjD5CTRlfo1PllsLOuapYa_Qu2nkkA4F1sLrB4sfDGaWeDY5Gqq1vLcXt6_EJG; 8_5ZXs-cEPcNeubkqPOFshxD0TK=; P6BWWR9LQB-firefly_1=eyJwYXJ0bmVyLXVpIjoidHJ1ZSJ9; Ta7-72v8skl6cLokjOZwUo-Q7wi=; pPJ406xOdkfoXZjvJWuGZTm1_d8=; LANG=en_US; x-pp-s=eyJ0IjoiMTQ2MTAwOTUwMDE3MCIsIm0iOiIwIn0; SPARTAJSESSIONID=69b5a8d755efb; SPARTAJSESSIONIDV2=zrwcayBAF52CfCT8n9Dm.bcQyugW8-7pfYQfYFsPqAhgH-mldcVOX7vDrVHICvhd8y4.BEcacTHGpgm8dLRCIjxfKYDj7hzQgp.yoseFr0gsqIbFTy8KLSknTmXY-9IjX0AJ9CYkzuVv5A-prbq.pqf9x6yiGmuZadB7XPSZcAMir2kgsU.KMxE8DVf6qmwZdSOwiGfL32b1e8vhOAF2Ah12TsRaTDI1id69o7I-BphXl.OFAgwHdg; analytics=IbVDJQAn5MDniiw63TGpWS3Uk8PysW-.b0JQiPeRlstu-DUyGLxaoI-nN4S9KvlerjnnejHzMC4; Tv7XaFXkAfcLyjkmtYddHHs5nwS=d4JWluHkdgoHzHq6FYJFLLVmr_rDej9WQcSAr_CDKP1vdppysAhATYGkfY-6vNmrQWpqhEBcbcofHgIpzN_y4pGqJqmwKeUz94VDxnvbMTypGva1SIQPEgk4ygKgjAeGjmHjkG; -1ILhdyICORs4hS4xTUr41S8iP0=D5NpyTY0HxIVJW2g5yKxP7roL-k_C5N3XxmPrMfuI_L6iS_pExwGTd1-I88DTXaAy7YNDlh26wjb8Soh; jIHSLr4M5Yy4U-3CrkGq73ovwuW=A103.syKD_069OlG6qbaZOEh94tflwhvswKNrp-yr9ZZlJBa7UNspj0EwIXJJmhoLonGk.QAzQhXF_NeKyC1jhsF-RTk-fO9u; id_token=; nsid=s%3Ao0X9PX_Y0MgM6-FRQGOg1LhncXESf7Nk.w2wDfP8JINv2eBKoCtHl1ijRxq4EzmhRVqjINc0SNcw; c9MWDuvPtT9GIMyPc3jwol1VSlO=I6DovXAn2H6HRG2ujtN4t8rojVBc8YLCLfywJYayUyjkGxnxAYSfvk0idSnpAuHxdAFwnn03sJwj1Kx0Hm3Tv-SAPSCzXigaNltq4eJm6ukRtg9oDw1bh1gpbVEZftkFpItym4wystx8LLOgYm4xxUJ1Nb7MUxh8V8r3RwWP6mVUMC7HHuOygIxNynbHQbePbhqKzm4A9nPav8Zj3bry7EOVgqlNZTersB1Q5URfdmKMq_bB9R4uoFBaM6u; i-mmSTyTsv6thyfmaQ1oZIPvE98=o8icCb2LVioho9nw8AAw0WKQ5LOTNV_mzfEaAiY0QP_aS7bj4sevFRccpMKTb91FX1RPvjpckLzscee6sT71E6VluTiwwoRvFAMtnPgSyO77BxwoTb64X7r0Z4-WAdW3qh75EVDcb35jcWSsqSqjDC6E1wA5tpkRG1u_c_8noC7nAGXomKtfjkjocSHeh5BwywRb6N0fulIvLzo_OjEVKt-ziYeAb03lDra-eaSuSVFvK_ncxH0epRUNaACHsglOlG64weE7HDVT-IkDSpyBjiZVMVvyPwWUAgCye3CYxECKJyIXhA0Dsr0w7xW-NlRboLbOcBG5almIpsR2mn1H6WIdlhDPBM2jN_wrEW; pNTcMTtQfrJuaJiwEnWXQ6yNxfq=-cNhrm0-H8ht6beuCftkxgLVbQqQmx3A6fTKD1VpnboSQ7lM-7EGMT0TVqxuDuocrZA3RmiQEMyGQzGzLniKz0AuloYWAmJlm6b1Z4UVWsYdIoMdxWTUgOEsIhSvuyHGFgoJ1E11uJ92w9rfWijw5pL_e6MpFxjTceZR__6qo1ROaRk0K1rKmfaIGKdGj2prtGKeIArZWltCZ3BKu7JDJGtX9j0cs-G4SKWPPurg4J5bA3YZ-OVYeSl4iPpbojGNEn5ovfQdjn7DB3hjg4CyYk5SPc4hG6EcP7NYPh6uksbtb1aJvkftoScHmn2mA_P64wISp75nED4y0KcJqSLfEdcMIEOHjJIZo7uRyyI0V58WVK3YX2DBknhSGl2IqPdCLRUKKJfc_PXmhralyDb2nlUYnbw1OOFMkflZ2k5EUhutN3odVMZQWDXhNCwwX_s2ee42LRk-69OMG8-Y3GPojtkXvaWFdN15qzyV9F4IG_E37ULmUIxVVCdLviylCCWjiJDOSGhCBKJ4wvAd4FIAa67xOmBjd0VhEehZnBVKKLT6VFTATTSB7K6W6Kss5txuQX65dC_QM-zKDL6PLs4iJJF_RWJ14HFEjkEXf6TabTk_S8b7JJ2svk6LvBenfJ3HkjblR6oYjfH0aXR3XJucixMpc06P9Me2ZjnWQ4rYz1SUKL254TwBfS86kVhlbfzSVOc7WHux_tTvsyDOS9hm2iZ3zE0Kb8zOGbLWklvIMY5o8lBL4Ningcfpk6pQ9wDEV64-P5dqMKXQ_yf5Y-ckwEG5AxV5CGFbsTHtobcApZ7paZ6pxjeTXHxd1A1W2Kxug9KrhmMEsRkD5vjjmJhwbGPMpRYIf6THi8aTti9oT55cNCkTX3pFMpkYwCKilLg8iVBLb3hCsx2ZiRsLnsZamUtB-T7OVQ-yg8jPPzwkw7UPJHi73Xp8Eka_3N8_OePC8dIrvBRRYp8xN9VoAQpPMgNJxm71G1xfTrg8E1g1Jkk3eXP6mT21M80WCIq2ZoYKX16ONCtl4sTIMQX6XTa_rxTiBY_haCTYTOghx8qCgLYYIyrHSE0QWpkFfWa4fg7G_UBQT9Nqq58bsMH_N0LAc5nW2GbGtsxi70-8tXGW5xxH0nt-svZDo3u_AAWnfxalP2nhcdY99bd3LVVHa17lSpiEJTd66XbdEj6i805wsSEKbxPCBZmBqo3XZLtahHMZ38-93ZTxUJCzsPJ57hRsu1FwrTd1HJtMuAoBGAcsQNKDdXiaf3-IXzqKMdLM-56hxsg_oCBpqAPjvoxE9iaC5-quJZE2UF4_0sDUsGVcH4Wv2O-00YqnQ7f_npnelCUNKNFxUM0IfspRFqqo177RlTjgcW2Inv5el6SHm8LaKOOXeVDvdHmbeDeoD7eyIznEO4gCBw0HZB_2pXH3dGMKnUSKxbDsbwg9iAjpGyMEKhufpHW1LGDx9NWWwa982n8gKHv6ElcWnTmjBEYYygUdyGCHbvsYHO7g0JDca0OQeyAIK9v2kFbiv-G2TVmpzrL5X95fW8dgPFXQkE0Zfj69Sc29JtrVBL3pfmYjLSs-v-Ap-BjVY5VGTNd4CzyeaePC26zm6H8JWFVyfbaR81x5cCvxnu0; X-PP-K=1464796892:5:NA; Obsh1bpwTE8slCzy4X2PwOLmhre=D103.sjSPDaMrGFiQ-n65Dwshid34rtRaqtf9gJcOeCrMS6A.abbFvvOlZOuQaML8JNEbTleXoke; x-csrf-jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbiI6ImVqLWtFM3RUMTZwaDhrZm1lZ05OSDlSd3JyU0FpYXdrUXoxYkxkLWJxNDBScVBwNVZjRXp3Wlo1T2k2REZGeE9kemxOOElVcExyemtINlVyT1NDRjMtUGp4bnl0YXB2WTctckNRWGhmdHRvdm5MRDR6S3hoU2tiYjBkc3MyMWVDMkY2ZURLdC1kbzBrQzBYejhsWVFfTUpCaTZadHVCMmdsNi0zZDBGYmpHeDBWYWktMjBuc3JYaTJCd3FsVGZkSnhjd2NVYVgwLTdXRmlUNzJQT3ozcTRMYUdzMCIsImlhdCI6MTQ2NDk3NzA3MCwiZXhwIjoxNDY0OTgwNjcwfQ.LnhIARq1QfGBvbBZacz0XhDlzYW84sWGjVpyUkmTrmk; AKDC=slc-b-origin-www-2.paypal.com; _gat=1; login_email=jason%40ucodemy.com; fn_dt=72960c2e3a054c13ba2c9bf236cf6bfa; KHcl0EuY7AKSMgfvHl7J5E7hPtK=Zv_aLJcUP8xF5AiqUTnrPOGq9LEyN_2CPF6JCQ80Q9xYiYSULMcPntn5H3k1YCG6K1QinVUf-seLv7Fe; ui_experience=login_type%3DEMAIL_PASSWORD%26home%3D3; DPz73K5mY4nlBaZpzRkjI3ZzAY3QMmrP=; AV894Kt2TSumQQrJwe-8mzmyREO=; X-PP-ADS=AToBjZEGV9EhlnBNNaTZvTV9FBvpYsY7AUBpKleCljtAOuPArRmEqd36WjBmOwE1UlNXQNLdelRDZjFYNL4Bd6Vq8w; SEGM=bRdV1vB0ebq9RKdAb3xSHowCi6QnnlCiDOLNk8i1mAuLl1vTbzHQwWajSsMe8mvoWiJtY1GnpzN4Y-sixGy7BQ; h3AkkNwOxPEPRslUIy3vhqkniPK=1MQj6iPRAu5-vhgNV0zkoRDIAAoSUqOCQ9fjKXzaQ3C_VKRUD5b7X5I58pK; VHzDQylDGxsX9ZzQOaL5x-ItYUu=dOgBqGUh_R8IWhaK2OL8pPfftLiRshO0hwpATEcafqNbEbb4rWdY357uWn_lRNKJhlhtibp79apsAiGbw9sx2EoAn80; cwrClyrK4LoCV1fydGbAxiNL6iG=6xj4lSfVCNifZzOknGKaz3vFMyvnGIftrBaWUAvSJrPlRrB3BjBtpgfbowD7rIqP_xxdd0vFkAK4PQwfXAebc07PenJ5sQWE6sgP4gwLwj4x3IIPm2xVjGNoTISZBznLJ38CAzhOnQGpPHZSbW1nIIOrTEEwYA9c-OxORUz2KB_ekSa7B7gHsBRtlwv761uMlvivYcXalfyYDQAC80UGSf6X1pgW4AHA5xZb4KdJQo0VQtr7Nmb_d39LqKMxUiiA6D56h8G_PBDDtTl-qC3_ZgG50EYJI72rRFaxf0Rdx_280DGwoFqCJWegT2Cl3wYpAraDsLD6mFZD-39CINVPI6E9T1x7n_U8wSvXD8odh4xBgXudLa3b45SWAb3j8zydHVaBJiQgPCDb2wlpp47MSe0bcaCCvqZw37QLUKXEK0M81n6qNgAECNaV-08; navlns=0.4.0; feel_cookie=a%2015%20_complaint-view%20b%2019%20_choose-transaction%20c%206%20webscr%20d%206%20webscr%20e%2051%20CaseManagement%2fcustomerservice%2fResolutionCenter.xsl%20f%2031%20History%2faccount%2fTransaction.xsl%20g%205%20en_US%20h%205%20en_US%20i%2051%20xpt%2fCaseManagement%2fcustomerservice%2fResolutionCenter%20j%2031%20xpt%2fHistory%2faccount%2fTransaction%20k%2026%20Resolution%20Center%20-%20PayPal%20l%2029%20Select%20a%20transaction%20-%20PayPal%20; s_pers=%20s_ev32%3D%255B%255B%252713680%25257C225003%25257CUNSUB%25257CPNP%2527%252C%25271435686403381%2527%255D%255D%7C1593539203380%3B%20s_fid%3D05AF6EADAEA33311-0237336D5D25A434%7C1528150385627%3B%20gpv_c43%3Dresolutioncenter%253Alanding%7C1465080185633%3B%20gpv_events%3Dno%2520value%7C1465080185637%3B; s_sess=%20v0%3D13680%257C225003%257CUNSUB%257CPNP%3B%20c_m%3DOther%2520Natural%2520Referrersundefinedwww.google.com%3B%20lt%3D%3B%20s_cc%3Dtrue%3B%20tr_p1%3Dresolutioncenter%253Alanding%3B%20s_sq%3D%3B%20v31%3DResolutionCenter%253ALanding%3B%20s_ppv%3D100%3B; navcmd=_login-done; consumer_display=USER_HOMEPAGE%3d3%26USER_TARGETPAGE%3d0%26USER_FILTER_CHOICE%3d0%26BALANCE_MODULE_STATE%3d1%26GIFT_BALANCE_MODULE_STATE%3d1%26LAST_SELECTED_ALIAS_ID%3d0%26RM_NAV%3d2%26SELLING_GROUP%3d1%26PAYMENT_AND_RISK_GROUP%3d1%26SHIPPING_GROUP%3d1%26MCE2_ELIGIBILITY%3d3; cookie_nav_is_vt_enabled=; cookie_nav_is_uum_enabled=; x-pp-p=xh4LPiqR3nDDhTURZZaNKtyLPzzs8shTH5oMBxG30OLJ5U3YN0ylPRShyLZVHMLLga3Io.uZnsPWbrDMmIc.HBNqM9ZCbcsD.p6y4pueAnxzGGglSKENHv6y4bllKw95FT6CxYXKM0QHlCkCsXO8g0PXOHd-9RTCKH1lfjZqkWAY-XCoXPAOyF9RN2twreyFLiQGB2VheeN0loxCQ1khMfdenPgZiqozHzGhCWnFUlO31PCWNhujR2ODJ4cW8xYE; LANG=en_US%3BUS; tsrce=bizexpnodeweb; X-PP-SILOVER=name%3DLIVE6.WEB.1%26silo_version%3D880%26app%3Dbizexpnodeweb%26TIME%3D894653271%26HTTP_X_PP_AZ_LOCATOR%3Dslcb.slc; ts=vreXpYrS%3D1559749360%26vteXpYrS%3D1465080383%26vr%3D5455203914d0a4a067b7727afe2414a8%26vt%3D1d7911c91550a4a59583eb93fcff3d6f; HaC80bwXscjqZ7KM6VOxULOB534=qwIGnYdm3pN_hU9H6g6DtihSLf6l2KDLHKXoKgueabn-KE6OGAfa5JuhgmQlncNh4m66nk4slq6NcYEXnv9ek__vMAzNw876rR2_NIWmVH1_oWUF_Jf6dL7UbSzQowNNEPDu4m; _ga=GA1.2.774544044.1431638976
Host:www.paypal.com
Referer:https://www.itchcode.com/create.html
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
I had and fix this issue.
Previously I accepted an untrusted certificate for my website on chrome. Then I change my certificate to a good one but chrome keep old certificate information.
When I do a payment test, paypal front redirect to a backurl that is not trusted to your chrome => the 502 error pop.
Solution is to refresh your certificate in your chrome.
I need to provide Facebook web access without using browser.
I'm using Play Framework for my needs, and send requests to FB API through web service.
I've checked request parameters for HTTP using firebug with disabled javascript, and handling all redirects to save cookies. But when I send filled form with all hidden parameters and cookies it sends redirect to login page, without token.
GET request with app_id and secret for registered web application:
https://www.facebook.com/dialog/oauth?client_id=xxxxxxxxxx&secret=yyyyyyyyyyyyyyyy&redirect_uri=https://myhost.com&response_type=token
It responds with redirect to https://www.facebook.com/login.php page with parameters:
skip_api_login=1
api_key=xxxx
signed_next=1
next=https%3A%2F%2Fwww.facebook.com%2Fv2.1%2Fdialog%2Foauth...
display=page
with reload parameter with same data and additional parameter: _fb_noscript=1
Further I'm retreiving data from login form and send it with POST request.
But it redirects me again to login page.
I'm filling my requests with same headers as Firefox do with updated mutable parameters from server response:
POST /login.php?login_attempt=1&next=https%3A%2F%2Fwww.facebook.com%2Fv2.1%2Fdialog%2Foauth%3Fredirect_uri%3Dhttps%253A%252F%252Flocalhost%253A9443%26response_type%3Dtoken%26client_id%3Dxxxxxxxxxxxx%26ret%3Dlogin HTTP/1.1
Host: www.facebook.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.facebook.com/login.php?skip_api_login=1&api_key=xxxxxxxxxxxx&signed_next=1&next=https%3A%2F%2Fwww.facebook.com%2Fv2.1%2Fdialog%2Foauth%3Fredirect_uri%3Dhttps%253A%252F%252Flocalhost%253A9443%26response_type%3Dtoken%26client_id%3Dxxxxxxxxxxxx%26ret%3Dlogin&cancel_uri=https%3A%2F%2Flocalhost%3A9443%2F%3Ferror%3Daccess_denied%26error_code%3D200%26error_description%3DPermissions%2Berror%26error_reason%3Duser_denied%23_%3D_&display=page&_fb_noscript=1
Cookie: datr=MnsEVMW8ZS7nkPtR2E4HrKko; reg_fb_ref=https%3A%2F%2Fwww.facebook.com%2Flogin.php%3Fskip_api_login%3D1%26api_key%3Dxxxxxxxxxxxx%26signed_next%3D1%26next%3Dhttps%253A%252F%252Fwww.facebook.com%252Fv2.1%252Fdialog%252Foauth%253Fredirect_uri%253Dhttps%25253A%25252F%25252Flocalhost%25253A9443%2526response_type%253Dtoken%2526client_id%253Dxxxxxxxxxxxx%2526ret%253Dlogin%26cancel_uri%3Dhttps%253A%252F%252Flocalhost%253A9443%252F%253Ferror%253Daccess_denied%2526error_code%253D200%2526error_description%253DPermissions%252Berror%2526error_reason%253Duser_denied%2523_%253D_%26display%3Dpage; reg_fb_gate=https%3A%2F%2Fwww.facebook.com%2Flogin.php%3Fskip_api_login%3D1%26api_key%3Dxxxxxxxxxxxx%26signed_next%3D1%26next%3Dhttps%253A%252F%252Fwww.facebook.com%252Fv2.1%252Fdialog%252Foauth%253Fredirect_uri%253Dhttps%25253A%25252F%25252Flocalhost%25253A9443%2526response_type%253Dtoken%2526client_id%253Dxxxxxxxxxxxx%2526ret%253Dlogin%26cancel_uri%3Dhttps%253A%252F%252Flocalhost%253A9443%252F%253Ferror%253Daccess_denied%2526error_code%253D200%2526error_description%253DPermissions%252Berror%2526error_reason%253Duser_denied%2523_%253D_%26display%3Dpage; noscript=1
Connection: keep-alive
Is there any way to get Facebook access token dirrectly by POST/GET requests without browser?
I am new to REST so bear with me if I'm missing something obvious.
Any pointer would be much appreciated as I am a bit lost.
Scenario
I needed to post some data to the following REST service: https://api.dotmailer.com/ from my web application https://myapp.com/.
During testing, I was able to post the data from my local pc.
However, as soon as I published the updated application to https://myapp.com/ on a remote server, I was no longer able to post any data.
What I've tried so far
Added rule to the remote server firewall to allow outgoing traffic to use https. Didn't solve the problem.
Disabled the url rewriting rule that change http to https for myapp.com. Didn't solve the problem.
Pasted the URL I use to post my data (https://api.dotmailer.com/v2/address-books/12345/contacts) in a browser on the remote server, entered the correct credentials, but couldn't access it.
the error message said "Unable to open this internet site. The requested site is either unavailable or cannot be found." If I do the same on my local PC I can access the URL.
Monitored the two calls with Fiddler2.
I include the results of the monitoring process below:
CALLS MADE FROM REMOTE SERVER
----------
POST /bla.aspx HTTP/1.1
Host: myapp.com
Connection: keep-alive
Content-Length: 10660
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: https://myapp.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Content-Type: application/x-www-form-urlencoded
DNT: 1
Referer: https://myapp.com/bla.aspx
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,it;q=0.6
Cookie: ASP.NET_SessionId=xxx; Myapp=xxx; GUID=xxx
CALLS MADE FROM LOCAL PC
----------
POST /bla.aspx HTTP/1.1
Host: localhost:xxx
Connection: keep-alive
Content-Length: 10656
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost:60675
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Content-Type: application/x-www-form-urlencoded
DNT: 1
Referer: http://localhost:xxx/bla.aspx
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,it;q=0.6
Cookie: __eqtUser=xxx; ASP.NET_SessionId=xxx; Myapp=xxx; GUID=xxx
Question
I believe point 3 shows that the cause is some setting on the remote server.
Does anyone know what it could be? Or am I completely off-track?
Update
I spoke with the developer on the receiving end of my calls who can monitor incoming traffic.
He could see my local calls but not the ones submitted from https://myapp.com.
In response to gmlime reply, I've added the following to myapp.com web.config file but didn't help.
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
</system.webServer>
Should I put it at a higher level in the hierarchy?
Make sure that this gets added to the response:
YourAddHeaderMethod("Access-Control-Allow-Origin", "*");
Many servers deny posting from other domains and can terminate the connection. You can learn more about it from the w3 docs for Access-Conrol-Allow-Origin and Mozzilla covers some scenarios. You may have to check with the server administrator to rule out cross domain problems also.