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.
Related
I am trying to reverse engineer an api request to a server that I don't control. Initially I view the following url (which doesn't require any credentials to logon):
https://www.abc.ca.gov/datport/lqs.html?rpttype=3&rptdateoffset=0
Using Chrome dev tool I see the data is displayed via the following url:
https://www.abc.ca.gov/LQSService.svc/LicenseRequest
I use this url in Postman as a POST request:
POST https://www.abc.ca.gov/LQSService.svc/LicenseRequest
Chrome tools shows the Request Payload which I use in the Body (raw) of the Postman request:
{"data":"<ROOT><PAGENUMBER>1</PAGENUMBER><RPTTYPE>3</RPTTYPE><RPTDATEOFFSET>0</RPTDATEOFFSET><RPTDATE>11/29/2017</RPTDATE><FORMATEDDATE>Wednesday, Nov 29, 2017</FORMATEDDATE><RPTGROUP>DAILY3</RPTGROUP></ROOT>"}
When I execute the request in Postman I get the following error:
{
"ExceptionDetail": null,
"ExceptionType": null,
"Message": "The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.",
"StackTrace": null
}
The Headers from the results show:
jsonerror →true
Chrome Request Headers also shows the following which I added to the Postman request (Headers) with the same error happening:
X-Requested-With:XMLHttpRequest
Cookie:ASPSESSIONIDCWQRCBDR=IBNIPHCCIGMJLKOPDMDJKCPJ
I also added the following Cookie in Postman as well:
ASPSESSIONIDCWQRCBDR=IBNIPHCCIGMJLKOPDMDJKCPJ; path=/; domain=.www.abc.ca.gov; Expires=Tue, 19 Jan 2038 03:14:07 GMT;
What else may I be missing or not specifying correctly in the Postman request?
The complete Request Headers as shown in Chrome are:
Accept:application/json, text/javascript, */*; q=0.01
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.9
Connection:keep-alive
Content-Length:210
Content-Type:application/json; charset=UTF-8
Cookie:ASPSESSIONIDCWQRCBDR=IBNIPHCCIGMJLKOPDMDJKCPJ; __utmt=1;
__utma=158387685.1745889465.1508735899.1512200444.1512230785.12;
__utmb=158387685.6.10.1512230783; __utmc=158387684;
__utmz=158387685.1512185091.8.2.utmcsr=google|utmccn=
(organic)|utmcmd=organic|utmctr=(not%20provided)
Host:www.abc.ca.gov
Origin:https://www.abc.ca.gov
Referer:https://www.abc.ca.gov/datport/lqs.html?
rpttype=3&rptdateoffset=0
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
X-Requested-With:XMLHttpRequest
Turns out I only needed to specify Content-Type in header.
I've had SonarQube running for a good while but haven't used it very much but in general stuff seems to have been working. I'm running it inside Docker.
I just updated it to LTS (6.7) and after that it seems to have gone into some limbo state. I'm able to log in and browse the website but as soon as I try to perform some operation (seems to not matter what that operation is), I get redirected to the login page. If I log in again, everything repeats. So I'm unable to actually perform any action it seems.
At first I thought this had to have something to do with old data conflicting with the new setup. So I cleaned everything out and set it up from scratch. The problem remains, I'm unable to do anything and get redirected to the login page every time.
For example, after the clean setup, I log in with admin/admin and I get the "first time tutorial" where I'm offered to create a token. I tried to do that but get directed to the login page. I log in again and this time I try to skip the tutorial but then I get redirected to the login page. Below is a part of the access.log for when I try to skip the tutorial:
10.3.1.119 - - [16/Nov/2017:00:12:48 +0000] "POST /gor-sq/api/users/skip_onboarding_tutorial HTTP/1.0" 401 - "https://build.acme.com/gor-sq/projects" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36" "AV/CJhNZndR3RsZuAAA4"
10.3.1.119 - - [16/Nov/2017:00:12:48 +0000] "GET /gor-sq/api/users/identity_providers HTTP/1.0" 200 24 "https://build.acme.com/gor-sq/sessions/new?return_to=%2Fgor-sq%2Fprojects" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36" "AV/CJhNZndR3RsZuAAA5"
10.3.1.119 - - [16/Nov/2017:00:12:48 +0000] "GET /gor-sq/api/navigation/global HTTP/1.0" 200 573 "https://build.acme.com/gor-sq/sessions/new?return_to=%2Fgor-sq%2Fprojects" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36" "AV/CJhNZndR3RsZuAAA6"
The first line indicates that the POST is getting a 401 response. Without being absolutely certain, it does look like it's the POST operations that are getting 401 responses while GET works.
This setup does sit behind a reverse proxy but as I said before, the setup has been working fine before and no changes have been made to the reverse proxy setup.
Hope I am not so late. I had the same issue. What worked for me is the deleting cookies from the browser and everything else works like a charm.
I had the same issue.
https://myserver.com/sonar/api/users/skip_onboarding_tutorial
I got 401 and I was redirected to the Login page. I looked at the source code and request.ts was erroring out at line 108.
submit(): Promise<Response> {
const { url, options } = this.getSubmitData({ ...getCSRFToken() });
return window.fetch((window as any).baseUrl + url, options);}
Looked like an issue with the CSRFToken. Since I have Sonarqube running behind a Nginx Reverse Proxy, there might have been something to do with the way I was handling the cookies.
So when I looked a little bit, I found the solution here:
https://stackoverflow.com/a/47909810/3221249
Basically, they changed the way you handle secure cookies after v6.0. Since I was making the cookie secure and httponly to true(not letting the client browser interact with the js code) I was having the above issue. I was doing this even before my non-ssl traffic hits Nginx. I have another proxy server running HAProxy which was handling this so I commented that part of the definitions.
#rspirep ^(Set-cookie:.*) \1;\ Secure if ! secure
#rspirep ^(Set-cookie:.*) \1;\ httponly
I hope this helps you.
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 :)
My web app can successfully create fitness.runs for myself and friends, but not for test users (created in the Test Users view of the Roles tab of the App's Dashboard). So I have a problem getting the app approved in the review, required for explicit sharing.
The app makes the following HTTP request to create (line breaks in content for readability):
POST /me/fitness.runs HTTP/1.1
Content-Type: application/x-www-form-urlencoded
course=https%3A%2F%2Fbroker-web.appspot.com%2Fpub%2Fcourse%2FagxzfmJyb2tlci13ZWJyLAsSDERQYXJ0aWNpcGFudBiAgICA_fCfCgwLEgZEU3BsaXQYgICAgICAgAoM
&start_time=2014-04-30T13%3A43%3A46
&expires_in=86400
&object=%7B%22app_id%22%3A%22255653361131262%22%2C%22title%22%3A%22Demo+410m%22%7D
&access_token=ACCESS_TOKEN
The successful response contains the action id (for myself and friends), and for test users the following error message is returned:
HTTP 500 OK
{error={message=An unexpected error has occurred. Please retry your request later., type=OAuthException, code=2}}
The crawler was successful visiting the object:
89.236.16.14 - - [30/Apr/2014:06:45:13 -0700] "GET /pub/course/agxzfmJyb2tlci13ZWJyLAsSDERQYXJ0aWNpcGFudBiAgICA_fCfCgwLEgZEU3BsaXQYgICAgICAgAoM HTTP/1.1" 200 6211 -
"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36"
"broker-web.appspot.com" ms=135 cpu_ms=41 cpm_usd=0.000694 app_engine_release=1.9.4 instance=00c61b117ce48a0349d573d3cd16b02587ffe00b
My app was using the wrong FB app ID when creating the action. That is an issue only for Test Users, as they exist for the correct FB App only.
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