Rocket Chat SAML - ADFS Logout issue - saml

I’m trying to use SAML with ADFS as identity provider but I got an issue during log-out that is blocking it. When I click on log-out I’m redirect to the ADFS webpage but I get stucked on error MSIS7054. As far as I understand it seems to be an issue with the certification during the log-out procedure.
Anyone could help me?
Here the details and logs…
Error from the log-out ADFS webpage:
Activity ID: 02d14948-b72a-4ae4-720d-0080010000d5
Error details: MSIS7054: The SAML logout did not complete properly.
Node name: 07f6ffc9-3f3b-4eed-96ab-2d56388c1d68
Error time: Wed, 09 Nov 2022 16:19:16 GMT
Cookie: enabled
User agent string: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0
ADFS logs:
The verification of the SAML message signature failed.
Message issuer: https://**********/rocket-chat/_saml/metadata/adfs-*****-com
Exception details:
MSIS7084: SAML logout request and logout response messages must be signed when using SAML HTTP Redirect or HTTP POST binding.
This request failed.
User Action
Verify that the message issuer configuration in the AD FS configuration database is up to date.
Configure the signing certificate for the specified issuer.
Verify that the issuer’s certificate is up to date.
Verify the issuer and server message signing requirements.
Rocket Chat logs:
I20221110-16:26:30.571(1) [2022-11-10T15:26:30.570Z] USERLVL (Meteor/31310 on ip-172-31-31-65): method: “samlLogout” userId: “iBDrzNcQ6B2W8DWgd” userAgent: “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36” referer: “” remoteIP: “*******” instanceId: “S7hZq3dHP8DMjA6EJ” I20221110-16:26:30.577(1) [2022-11-10T15:26:30.577Z] USERLVL (API/31310 on ip-172-31-31-65): status: 200 responseTime: 7 method: “POST” url: “/api/v1/method.call/samlLogout” userId: “iBDrzNcQ6B2W8DWgd” userAgent: “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36” length: “111” host: “**" referer: “” remoteIP: "”
Server Setup Information
Version of Rocket.Chat Server: 4.1.0-17.7
Operating System: Debian 9
Deployment Method: tar
Number of Running Instances: 1
DB Replicaset Oplog:
NodeJS Version: 12.22.1
MongoDB Version: 5.0.2
Proxy: nginx
Firewalls involved: yes
I've tried multiple configurations on either side but nothing worked.

Related

Keycloak OIDC and AWS ALBs

Is there a way to get Keycloak to work as an OIDC Provider for AWS ALBs?
I have tried and tried and I am just getting stuck with 500 Internal Server.
I created a new confidential client and provided the ALB with the clientID and secret as well as the OIDC Urls. I read a few years back about an issue with Bearer vs bearer in the headers, but I couldn't validate that this was the issue, or that it is still an issue with ALBs.
Any help is appreciated.
EDIT: This is my configuration. I have adjusted the URLs to be generic.
AWS -
Issuer: https://login.example.com/auth/realms/example
Auth Endpoint: https://login.example.com/auth/realms/example/protocol/openid-connect/auth
Token Endpoint: https://login.example.com/auth/realms/example/protocol/openid-connect/token
User info Endpoint: https://login.example.com/auth/realms/example/protocol/openid-connect/userinfo
Client ID: ExampleApp
Client secret: supersecret
aws_oidc_settings
Keycloak -
Client ID: ExampleApp
Root URL: https://li.stagingweb.example.com
Valid Redirect URIs: https://li.stagingweb.example.com/*
Admin URL: https://li.stagingweb.example.com
Web Origins: https://li.stagingweb.example.com/*
keycloak_client_settings
keycloak_cred_settings
The response I get back from this configuration is just a 500 error. The Load Balancer logs report:
5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 -"li.stagingweb.example.com" -1 2020-04-27T18:11:34.497000Z "authenticate" "-" "AuthTokenEpRequestFailed" "-" "-"
This is the request that gets the 500 error:
https://li.stagingweb.example.com/oauth2/idpresponse?state=PWISnbHmRCVpxmqyn%2FrKsHdJzbKFnfz5GxhnlCyVdnxRVV%2F9kvj7O0JCjQOuf1DNL08h821PorJGGa3%2F4fzFymulG8sS%2FxhLFQS5gNrpuQyCf9DCzrwFxkIbG3I2sHywK7%2FeDmfYUH6Rej%2FEJ4RQwdjpjm76Z1wycw%2FGjQIRxehaTqNtCS%2FdXhm2oag%2FBnY%2FkuMiB8Q%3D&session_state=3a94a1d6-5e75-491b-a231-e4a1a469e5cb&code=23364bac-92e9-4094-9dc3-19c15eb42e7c.3a94a1d6-5e75-491b-a231-e4a1a469e5cb.9723ee49-5bca-4ff6-8a13-f7539b0bc28c
Hopefully I didn't post any info I shouldn't have :)

Using Postman get 500 Internal error sending payload

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.

Getting bad gateway 502 response from Paypal

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.

How to post data with REST service from remote server

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.

The domain is inserted right but FB login still gives a "the given url is not allowed by the application configuration"

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