Request on the localhost working correctly and on the server returning 302 code

Asked

Viewed 118 times

1

I’m using guzzle to request an API in the login endpoint.
When using my server on the localhost, the request is usually made, when I upload the code to the server, the same request works the first time, and after that always returns the code 302 and redirects me to the localhost. Does anyone have any idea?

use GuzzleHttp\Client;

$api = new Client([
    'headers' => [
        'User-Agent' => 'Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Mobile Safari/537.36',
        'Accept' => 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8',
        'Cache-Control' => 'no-cache',
        'X-Requested-With' => 'XMLHttpRequest',
        'Accept-Encoding' => 'gzip, deflate, br',
        'Connection' => 'keep-alive',
        'Accept-Language' => 'pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7'
    ],
    'base_uri' => URI,
    'cookies' => true,
    'verify' => false
]);

$login = $api->post('https://members.bet365.com/lp/default.aspx', [
    'form_params' => [
        'txtUserName' => $username,
        'txtPassword' => $password,
        'txtType' => 47
    ],
    'debug' => fopen('php://stderr', 'w+'),
]);
print_r($login->getBody()->getContents());

In debug tracking returns this to me in localhost

*   Trying 5.226.176.7:443...
* Connected to members.bet365.com (5.226.176.7) port 443 (#0)
* ALPN, offering http/1.1
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=GB; L=Stoke-on-Trent; O=bet365 Group Limited; CN=*.bet365.com
*  start date: Dec  7 00:00:00 2020 GMT
*  expire date: Jan  7 23:59:59 2022 GMT
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=Thawte RSA CA 2018
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> POST /lp/default.aspx HTTP/1.1
Host: members.bet365.com
User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Mobile Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Cache-Control: no-cache
X-Requested-With: XMLHttpRequest
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Accept-Language: pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7
Content-Type: application/x-www-form-urlencoded
Content-Length: 57

* upload completely sent off: 57 out of 57 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Cache-Control: private
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Content-Encoding: gzip
< Vary: Accept-Encoding
< Referrer-Policy: no-referrer-when-downgrade
< Access-Control-Allow-Origin: https://www.bet365.com
< Access-Control-Allow-Credentials: true
< lf: uls=1
< Set-Cookie: session=processform=0; path=/; secure ; SameSite=None
< Set-Cookie: pstk=CFC49C91E6DA47B2853FF5090C0CB37E000004; domain=.bet365.com; expires=Mon, 18-Jan-2021 10:06:35 GMT; path=/; secure ; SameSite=None
< Set-Cookie: aps03=lng=33&tzi=16&ct=28&cst=0&cg=1; expires=Fri, 17-Jan-2031 21:06:34 GMT; path=/; secure ; SameSite=None
< Set-Cookie: aaat=di=643f1c44-052d-4c11-aaec-5aeba6784ace&am=0&at=81da8cc7-0e11-483e-a742-d5534209ff02&un=htgabriel&ts=17-01-2021 21:06:35&v=2; domain=.bet365.com; expires=Fri, 17-Jan-2031 21:06:34 GMT; path=/; secure ; SameSite=None
< Set-Cookie: usdi=uqid=10D2B512-224E-421A-855A-58EB260E7187; expires=Fri, 17-Jan-2031 21:06:35 GMT; path=/; secure ; SameSite=None; path=/; secure
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Strict-Transport-Security: max-age=31536000; includeSubdomains=true
< Date: Sun, 17 Jan 2021 21:06:35 GMT
< Content-Length: 484
<
* Connection #0 to host members.bet365.com left intact

And return it to me after I’ve climbed to the server

*   Trying 5.226.176.7...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55d18385bac0)
* Connected to members.bet365.com (5.226.176.7) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=GB; L=Stoke-on-Trent; O=bet365 Group Limited; CN=*.bet365.com
*  start date: Dec  7 00:00:00 2020 GMT
*  expire date: Jan  7 23:59:59 2022 GMT
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=Thawte RSA CA 2018
*  SSL certificate verify ok.
> POST /lp/default.aspx HTTP/1.1
Host: members.bet365.com
User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Mobile Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Cache-Control: no-cache
X-Requested-With: XMLHttpRequest
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Accept-Language: pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: pstk=5FB3D6964EA543DD95EC42CD0A66266C000004; aaat=di=84ca5961-2f8f-4108-89a2-86b34d412b1f&am=0&at=ce19b0c0-924e-4acd-959a-bf4cdecf008b&un=htgabriel&ts=17-01-2021 21:01:17&v=2
Content-Type: application/x-www-form-urlencoded
Content-Length: 55

* upload completely sent off: 55 out of 55 bytes
< HTTP/1.1 302 Found : Moved Temporarily
< Location: http://localhost
< Cache-Control: private, no-cache, max-age=0, no-store, must-revalidate
< Expires: Thu, 01 Jan 1970 00:00:01 +0000
< Pragma: no-cache
* no chunk, no close, no size. Assume close to signal end
< 
* Closing connection 0

*   Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 75000 ms for 3 (transfer 0x55d18385bac0)
* Expire in 200 ms for 4 (transfer 0x55d18385bac0)
* Connected to localhost (127.0.0.1) port 80 (#1)
> GET / HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Mobile Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Cache-Control: no-cache
X-Requested-With: XMLHttpRequest
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Accept-Language: pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: pstk=5FB3D6964EA543DD95EC42CD0A66266C000004; aaat=di=84ca5961-2f8f-4108-89a2-86b34d412b1f&am=0&at=ce19b0c0-924e-4acd-959a-bf4cdecf008b&un=htgabriel&ts=17-01-2021 21:01:17&v=2
Content-Type: application/x-www-form-urlencoded

< HTTP/1.1 200 OK
< Date: Sun, 17 Jan 2021 21:53:48 GMT
< Server: Apache
< Vary: X-Proxy-Provider,Accept-Encoding
< Upgrade: h2,h2c
< Connection: Upgrade, Keep-Alive
< Last-Modified: Sun, 17 Jan 2021 20:29:40 GMT
< Accept-Ranges: none
< Content-Encoding: gzip
< Cache-Control: max-age=86400, must-revalidate
< Expires: Sun, 17 Jan 2021 22:53:48 GMT
< Content-Length: 92
< Keep-Alive: timeout=5, max=100
< Content-Type: text/html
< 
* Connection #1 to host localhost left intact

The code that is returned to me on the first request to the server (the only one that works)

*   Trying 5.226.176.7...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x560fd0a79d40)
* Connected to members.bet365.com (5.226.176.7) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=GB; L=Stoke-on-Trent; O=bet365 Group Limited; CN=*.bet365.com
*  start date: Dec  7 00:00:00 2020 GMT
*  expire date: Jan  7 23:59:59 2022 GMT
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=Thawte RSA CA 2018
*  SSL certificate verify ok.
> POST /lp/default.aspx HTTP/1.1
Host: members.bet365.com
User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Mobile Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Cache-Control: no-cache
X-Requested-With: XMLHttpRequest
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Accept-Language: pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7
Content-Type: application/x-www-form-urlencoded
Content-Length: 57

* upload completely sent off: 57 out of 57 bytes
< HTTP/1.1 200 OK
< Cache-Control: private
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Content-Encoding: gzip
< Vary: Accept-Encoding
< Referrer-Policy: no-referrer-when-downgrade
< Access-Control-Allow-Origin: https://www.bet365.com
< Access-Control-Allow-Credentials: true
< lf: uls=1
< Set-Cookie: session=processform=0; path=/; secure ; SameSite=None
< Set-Cookie: pstk=FE060B3F9CD73CBF98C43B3F7E24C6D0000004; domain=.bet365.com; expires=Wed, 20-Jan-2021 08:30:07 GMT; path=/; secure ; SameSite=None
< Set-Cookie: aps03=lng=33&tzi=16&ct=28&cst=0&cg=1; expires=Sun, 19-Jan-2031 19:30:06 GMT; path=/; secure ; SameSite=None
< Set-Cookie: aaat=di=e59bcb90-81f5-4c34-9d92-7d658db6b6b4&am=0&at=6ed16c5f-8d5e-4a99-a470-dc5f37ea1c1a&un=htgabriel&ts=19-01-2021 19:30:07&v=2; domain=.bet365.com; expires=Sun, 19-Jan-2031 19:30:06 GMT; path=/; secure ; SameSite=None
< Set-Cookie: usdi=uqid=6DE27CD9-8936-43A1-9704-3A9CFEE0E8B1; expires=Sun, 19-Jan-2031 19:30:07 GMT; path=/; secure ; SameSite=None; path=/; secure
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Strict-Transport-Security: max-age=31536000; includeSubdomains=true
< Date: Tue, 19 Jan 2021 19:30:07 GMT
< Content-Length: 480
< 
* Connection #0 to host members.bet365.com left intact
{"txtLH":"","txtTS":"","txtLS":"1","txtLUN":"htgabriel","txtIT":"0","txtdbID":"0","txtSA":"0","txtLHV2":"","standardAtTkn":"6ed16c5f-8d5e-4a99-a470-dc5f37ea1c1a","standardAtTknExpires":"2022-01-19T19:30:07.1115566+00:00","uqid":null,"countryCode":"BR","authenticationStatus":"Authenticated","sessionId":"FE060B3F9CD73CBF98C43B3F7E24C6D0000004","sessionCookieExpires":"2021-01-20T08:30:07.2621597+00:00","deviceId":"e59bcb90-81f5-4c34-9d92-7d658db6b6b4","txtSTKN":"","notificationsRequired":false,"notificationsActive":true}
  • There is a difference between the two... The second already includes cookies (Cookie: pstk=5FB3D6964EA543DD95EC42CD0A66266C000004; aaat=di=84ca5961-2f8f-4108-89a2-86b34d412b1f&am=0&at=ce19b0c0-924e-4acd-959a-bf4cdecf008b&un=htgabriel&ts=17-01-2021 21:01:17&v=2) in the request. While in the localhost does not include these cookies, and these cookies are precisely the server response (via Set-Cookie). In short: In your first debug there is no cookie in the request; In your second debug there is a cookie.

  • But if cookies are precisely the answer of the server, why on the site it came and on the server not? Just these doubts that having you

  • Because on the server cookies have already been sent. There is no reason why the website should resend cookies, since you already have them. Note that in your request (no reply! ) you already include cookies in your second debug. While in the first debug you do not include cookies. Note the "Cookie" and the "Set-Cookie". "Set-Cookie" (which defines cookies) only exists in the first debug. In the second you (customer) is the one who sends the cookies (via "Cookie").

  • Try turning off the 'cookies' => true. If this is some kind of cookiejar, maybe this is what’s using cookies. So much so that in your question you say: "the same request works the first time, and after that always returns the code 302 and redirects me to localhost.". It works once, this time sets cookies in a cookiejar. Any "next time" will re-use cookies already set, which will return to localhost. No?!

  • I ran a test and turned off the cookies, but they’re still there in the request, I’ll wait a few hours until they come out of the cache or something, then I’ll get back to you if I succeed

  • I edited the question and added the code block that is returned from the server the first time, when it works

  • Did the answer serve? Managed to solve the problem using another solution?

  • Unfortunately I have not yet succeeded, even changing all the cookies, it is strange because even setting the cookies as false, I still see them in the requests, had given a pause to think better but still unsuccessful

  • Another thing I noticed was that making the request using the Axios in Nodejs it returns me an error 405

Show 4 more comments

1 answer

0

The "reason" is in the comments, but in short: The only difference between the two requests is that one already includes cookies and the other not.

Note that "the only one that works" and "on the localhost" DO NOT include the Cookie headers. Cookies are received as responses, since when you request the page they are missing.


OBSERVING: I never used this library (but I already used Curl, which Guzzle uses or used). I no longer use PHP and have no way to test the codes. So the codes posted here may need some correction.


Seeing the Guzzle documentation:

When Creating a client, you can set the default cookie option to true to use a Shared cookie Session Associated with the client.

The documentation does not say that cookies are persistent or not, however it says that they will be shared among customers (I suppose among the GuzzleHttp\Client).

This may be why the cookie is reused.

When your first request works, Guzzle saves cookies, so any subsequent request will already send Cookies. As a result, the website will not re-send cookies.


One way to fix it should be to turn off cookies by changing to 'cookies' => false, but there is another way that is creating a new CookieJar:

$api = new Client([
    'headers' => [
        'User-Agent' => 'Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Mobile Safari/537.36',
        'Accept' => 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8',
        'Cache-Control' => 'no-cache',
        'X-Requested-With' => 'XMLHttpRequest',
        'Accept-Encoding' => 'gzip, deflate, br',
        'Connection' => 'keep-alive',
        'Accept-Language' => 'pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7'
    ],
    'base_uri' => URI,
    'verify' => false
]);


// Novo CookieJar:
$cookieJar = new \GuzzleHttp\Cookie\CookieJar();

$login = $api->post('https://members.bet365.com/lp/default.aspx', [
    'form_params' => [
        'txtUserName' => $username,
        'txtPassword' => $password,
        'txtType' => 47
    ],
    'cookies' => $cookieJar, // << Especifica o CookieJar.
    'debug' => fopen('php://stderr', 'w+'),
]);

// Deleta os cookies (talvez desnecessário):
$cookieJar->Clear();

In theory, this should cause a new (and clean) cookieJar be used, so no request will recycle cookies, after all each will have a new Cookiejar.


I didn’t find many documentations about Cookiejar, but here’s some information: https://docs.guzzlephp.org/en/stable/quickstart.html#cookies and also in https://docs.guzzlephp.org/en/stable/request-options.html#cookies.

You can also read the cookies obtained from the previous answer using the $cookieJar (before erasing), can use something like:

$pstk = $cookieJar->getCookieByName('pstk')->getValue(); 
// Resultado: 5FB3D6964EA543DD95EC42CD0A66266C000004

Browser other questions tagged

You are not signed in. Login or sign up in order to post.