I am programmatically creating test accounts, and then immediately trying to log in w/ them using a selenium driven browser. Unfortunately, the browser is just redirected to the facebook homepage. I can briefly see what appears to be the correct url prior to the redirect flash by, so I have no reason to believe the browser isn't going where I intend it to.
That said, if create a fake account, and then just paste the login_url into a browser, things work fine. Anyone have any idea why that might be unique about using Selenium here? Is there anything I need to do to prepare the browser for https connections or anything?
All I'm doing is this: (using capybara and the Selenium web driver)
visit #fake_user.login_url
https://www.facebook.com/platform/test_account_login.php?user_id=100002152974488&n=ILRvb8Lqf2cq05t
GET /platform/test_account_login.php?user_id=100002152974488&n=ILRvb8Lqf2cq05t HTTP/1.1
Host: www.facebook.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15
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
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
HTTP/1.1 302 Found
Cache-Control: private, no-cache, no-store, must-revalidate
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location: http://www.facebook.com/
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
Pragma: no-cache
Set-Cookie: datr=d3J_TWSAN5uIXyh94O1YJkJ8; expires=Thu, 14-Mar-2013 14:06:47 GMT; path=/; domain=.facebook.com; httponly
Set-Cookie: lsd=-Lv-N; path=/; domain=.facebook.com
Content-Type: text/html; charset=utf-8
X-Powered-By: HPHP
X-FB-Server: 10.52.145.67
X-Cnection: close
Date: Tue, 15 Mar 2011 14:06:47 GMT
Content-Length: 0
http://www.facebook.com/
GET / HTTP/1.1
Host: www.facebook.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15
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
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: datr=d3J_TWSAN5uIXyh94O1YJkJ8; lsd=-Lv-N
HTTP/1.1 200 OK
Cache-Control: private, no-cache, no-store, must-revalidate
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
Pragma: no-cache
Set-Cookie: reg_fb_gate=http%3A%2F%2Fwww.facebook.com%2F; path=/; domain=.facebook.com
Set-Cookie: reg_fb_ref=http%3A%2F%2Fwww.facebook.com%2F; path=/; domain=.facebook.com
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Powered-By: HPHP
X-FB-Server: 10.52.163.25
X-Cnection: close
Transfer-Encoding: chunked
Date: Tue, 15 Mar 2011 14:06:47 GMT
Visit Facebook home page before trying to visit login url:
visit "https://www.facebook.com"
visit #fake_user.login_url
I haven't checked the headers, but I guess Facebook sets some cookies that are needed to log in.
Related
I am using traefik in kubernetes and I have a service deployed that is returning 103 Early Hint. I can confirm that it is working by directly querying the service, e.g.
curl -D - http://contra-web-app
HTTP/1.1 103 Early Hints
Link: <https://builds.contra.com>; rel="preconnect"; crossorigin
Link: <https://fonts.googleapis.com/css2?family=Inter:wght#400;500;600;700;900&display=swap>; rel="preload"; as="font"
Link: <https://builds.contra.com/3f509d0cc/assets/entry-client-routing.4f895d55.js>; rel="modulepreload"; as="script"; crossorigin
Link: <https://www.googletagmanager.com/gtag/js?id=G-96H5NXQ2PR>; rel="preload"; as="script"
HTTP/1.1 200 OK
cache-control: no-store
referrer-policy: strict-origin-when-cross-origin
x-frame-options: sameorigin
content-type: text/html
content-length: 9062
Date: Tue, 26 Jul 2022 20:34:19 GMT
Connection: keep-alive
Keep-Alive: timeout=72
However, requesting the same service through Traefik just returns 200 response:
curl -H 'host: contra.com' -D - http://contra-traefik.traefik/gajus
HTTP/1.1 200 OK
Cache-Control: no-store
Content-Length: 11441
Content-Type: text/html
Date: Tue, 26 Jul 2022 19:51:48 GMT
Referrer-Policy: strict-origin-when-cross-origin
Set-Cookie: contra_web_app_service=394e7e912ad85b66; Path=/; Secure
Vary: Accept-Encoding
X-Frame-Options: sameorigi
At this point, I am unable to establish whether I am missing a configuration or if Traefik does not support it.
In Web/List Module when clicking for example on Hide content Element the icon is changing from "actions-edit-hide" to "spinner-circle-dark", but not into "actions-edit-unhide". When Refreshing the page manually the right icon is shown. It seems that the AJAX Call doesn't refresh the list. This happens also by other actions, for example when deleting some Records.
We are Running TYPO3 8.7 LTS with MySQL 5.7.26 und PHP 7.2.17-0ubuntu0.18.04.1
When looking in my Browsers Network Analyse, i see the following call:
https://2019.mbaec.de/typo3/index.php?ajaxID=%2Fajax%2Frecord%2Fprocess&ajaxToken=976157b65a4042508b6b375cf09a50ea17110b90&data[pages][376][hidden]=0
Header:
Host: 2019.mbaec.de
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: application/json, text/javascript, /; q=0.01
Accept-Language: fr,de;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://2019.mbaec.de/typo3/index.php?M=web_list&moduleToken=73ba2ec59dbfe41e0d9e1b38af45dfdebd5b2b89&id=211&
X-Requested-With: XMLHttpRequest
Connection: keep-alive
Cookie: be_lastLoginProvider=1433416747; be_typo_user=5d6f974af357ad400e1380459174c539; Typo3InstallTool=vgehc4q4fs06ph6jn0f7pmg4rd
Result Header:
HTTP/1.1 200 OK
Date: Mon, 27 May 2019 13:48:15 GMT
Server: Apache/2.4.29 (Ubuntu)
Expires: 0
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
X-Frame-Options: SAMEORIGIN
X-JSON: true
Last-Modified: Mon, 27 May 2019 13:48:15 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Access-Control-Expose-Headers: Content-Length, X-JSON
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Accept, Contet-Type, X-Forwarded-For, X-Prototype-Version, X-Requested-With
Access-Control-Allow-Methods: GET, OPTIONS, PUT, POST
X-UA-Compatible: IE=edge
X-Content-Type-Options: nosniff
Content-Length: 64
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/json; charset=utf-8
Result:
{"redirect":"","messages":[],"hasErrors":true}
This issue was fixed with 8.7.26 (2019-05-09 82429eb0b0 [BUGFIX] Set hasErrors depending on existing errors). Are you sure all your opcode cache was emptied and that you're really on 8.7.26? 8.7.25 introduced that error as a regression. See https://forge.typo3.org/issues/87971
I'm learning Keycloak and I have the following problem.
I have a Java EE application protected through Keycloak (main-app). After logging into keycloak, it accesses another application (app-example, also protected by keycloak) that performs a check and depending on the result returns to main-app or shows an error.
The problem is that app-example redirects to keycloak and keycloak redirects back to app-example. At the end, I get the error: 400 bad request.
In front of keycloak I have an Apache server that acts as a proxy and all connections are via SSL.
First call:
Request URL: https://localhost/app-example
Request Method: GET
Status Code: 302 Found
Remote Address: xxx.xxx.xxx.xxx:443
Referrer Policy: no-referrer-when-downgrade
Connection: Keep-Alive
Content-Length: 0
Date: Mon, 17 Dec 2018 14:09:07 GMT
Keep-Alive: timeout=5, max=96
Location: https://localhost/auth/realms/my-realm/protocol/openid-connect/auth?response_type=code&client_id=appexample&redirect_uri=https%3A%2F%2Flocalhost%2Fapp-example%2F&state=e327185a-6306-4124-b384-215954f51bb7&login=true&scope=openid
Server: Apache/2.4.10 (Debian) mod_jk/1.2.37 OpenSSL/1.0.1t
Set-Cookie: OAuth_Token_Request_State=e327185a-6306-4124-b384-215954f51bb7; Version=1; Secure; HttpOnly
Set-Cookie: JSESSIONID=AxzD3hq5sfv-SJdbSa7HDLJe1lBWC1ExBoy86TdR; path=/app-example
Strict-Transport-Security: max-age=15768000
X-Powered-By: Undertow/1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: es-ES,es;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Cookie: OAuth_Token_Request_State=6f634ef2-cc69-4cb8-bdaa-2d69929b26a8; JSESSIONID=BVzI9MiQB6FYFIUDLyK2dQU_o6OPSCyZB9NQDfXV
Host: localhost
Pragma: no-cache
Referer: https://localhost/main-app/
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
Second call:
Request URL: https://localhost/auth/realms/my-realm/protocol/openid-connect/auth?response_type=code&client_id=app-example&redirect_uri=https%3A%2F%2Flocalhost%2Fapp-example%2F&state=e327185a-6306-4124-b384-215954f51bb7&login=true&scope=openid
Request Method: GET
Status Code: 302 Found
Remote Address: xxx.xxx.xxx.xxx:443
Referrer Policy: no-referrer-when-downgrade
Cache-Control: no-store, must-revalidate, max-age=0
Connection: Keep-Alive
Content-Length: 0
Date: Mon, 17 Dec 2018 14:09:08 GMT
Keep-Alive: timeout=10
Location: https://localhost/app-example/?state=e327185a-6306-4124-b384-215954f51bb7&session_state=39fc0c37-e60d-42e7-876a-97501753bd6a&code=eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..pDbVJYc-fWIWXhsycldqHA.4nZs2gTZZyNhHRDDF3vjd99vCmM6INRMGk8T-Svcc6U1nxtFu7am_Ck2oTNZKYs0_zRHzgUkU4mzmdfRrTRoN64b4uosAVvZKSx_UDhaOERbaLk4p1wqjAUswc2N-48Vb92XBPr-ihET5WF3mzcGeb2TK6k1_GjaBLdEz4BlO8cYVisp35HNIq1APR7GPh9UbCrJaspLegxrvY5_lM9GPsF3NwWorWFE8G3BeUSQeqF7CwTY4YXJnTPkarbwaYX9.-uqvbrqkLz2JLLjeBl4n3g
P3P: CP="This is not a P3P policy!"
Referrer-Policy: no-referrer-when-downgrade
Server: Apache
Set-Cookie: AUTH_SESSION_ID=39fc0c37-e60d-42e7-876a-97501753bd6a.public:server-public-1; Version=1; Path=/auth/realms/my-realm/; Secure; HttpOnly
Set-Cookie: KC_RESTART=eyJhb....9Y3M; Version=1; Path=/auth/realms/my-realm/; Secure; HttpOnly
Set-Cookie: KEYCLOAK_SESSION=my-realm/f24b7ee7-b32e-4e93-821f-cfbf4708acf4/39fc0c37-e60d-42e7-876a-97501753bd6a; Version=1; Expires=Tue, 18-Dec-2018 00:09:08 GMT; Max-Age=36000; Path=/auth/realms/my-realm/; Secure
Set-Cookie: KEYCLOAK_REMEMBER_ME=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/my-realm/; Secure; HttpOnly
Strict-Transport-Security: max-age=15768000
X-Content-Type-Options: nosniff
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: es-ES,es;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Cookie: KEYCLOAK_LOCALE=es; AUTH_SESSION_ID=39fc0c37-e60d-42e7-876a-97501753bd6a.public:server-public-1; KEYCLOAK_SESSION=my-realm/f24b7ee7-b32e-4e93-821f-cfbf4708acf4/39fc0c37-e60d-42e7-876a-97501753bd6a; KEYCLOAK_IDENTITY=eyJhb.....Qgs
Host: localhost
Pragma: no-cache
Referer: https://localhost/main-app/
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
response_type: code
client_id: appexample
redirect_uri: https://localhost/app-example/
state: e327185a-6306-4124-b384-215954f51bb7
login: true
scope: openid
scope: openid
In the log I observe:
ERROR [io.undertow.request] (default task-73) UT005023: Exception handling request to /main-app/launcher.jsp: org.apache.jasper.JasperException: java.lang.RuntimeException: java.lang.IllegalStateException: UT000139: Exchange already complete
I checked that the json file I got from keycloak and integrated into the application is correct. What's the problem?
cheers
Have you tried clearing your cookies?
In case you're using chrome:
https://support.google.com/chrome/answer/6098869?visit_id=637347644493186330-3872337140&p=rl_error&hl=en-GB&rd=1#redirect
Also using private window will likely help. In my case this was caused by running multiple keycloak instances on localhost over time, which got their cookies mixed up.
A Laravel app is using the JSTree to display files.
If I get the tree under http://localhost:8000 I recive the correct tree.
We have a ngnix reverse Proxy setting to access the web site from behind a proxy.
But if I open the ngnix web site there are in some cases no data. The ajax response is correct, but JSTree doesn't render it.
Have anybody a idea?
First I tried out the jstree().last_error() function and it is a empty object.
Here are my header, I hope it helps:
Host: DOMAIN.de
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://DOMAIN.de/explorer/show/443
Content-Length: 6
Cookie: cartalyst_sentinel=eyJpdiI6I...iJ9; laravel_session=eyJp...J9
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
The response:
Cache-Control: private, must-revalidate
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Date: Tue, 12 Apr 2016 06:37:12 GMT
Expires: -1
Host: DOMAIN.de
Pragma: no-cache
Server: nginx/1.4.6 (Ubuntu)
Set-Cookie: laravel_session=eyJpdi......3D; expires=Tue, 12-Apr-2016 08:37:35 GMT; Max-Age=7200; path=/; httponly
Transfer-Encoding: chunked
X-Powered-By: PHP/5.6.19
The PHP header:
header('Content-Type: application/json; charset=utf-8');
The problem is, with ngnix the response has another Content-Type. ngnix put "application/json" to "text/html".
Are there any options to modify this?
FB doesn't seem to respect ACCEPT headers sent to /feeds/page.php. See below example:
GET /feeds/page.php?id=10036618151&format=rss20 HTTP/1.1
Connection: Keep-Alive
**Accept: text/xml,application/xml**
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)
Host: www.facebook.com
HTTP/1.1 200 OK
Cache-Control: private, no-cache, no-store, must-revalidate
**Content-type: application/rss+xml**
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Last-Modified: Wed, 08 Feb 2012 10:05:49 -0800
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
Pragma: no-cache
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Set-Cookie: datr=-vIzT4cxw52hjjqTfrpQkNYX; expires=Sat, 08-Feb-2014 16:23:22 GMT;path=/; domain=.facebook.com; httponly
X-FB-Debug: qx/SiyRZDiVPm4wfiKVj37HImPoKM+DVAsO4oKSbSr0=
X-Cnection: close
Date: Thu, 09 Feb 2012 16:23:22 GMT
Content-Length: 41236
I cannot seem to find a way to post a new bug report on http://developers.facebook.com/bugs, as I don't have the "Create" (nor the "Subscribe") buttons as described here http://developers.facebook.com/blog/post/559/
I have read that there are a fair few FB developers involved with this site, and was hoping that someone could shed some light on what I might be doing wrong / how to request FB changes the code to respect my request, or 406 me.
You are going to want to verify yourself as a developer in order to create a bug.
Check out this link for verification via -
mobile number
credit card
Once you have verified your account, head back to the bug system.