I was getting following response after making a curl request to an endpoint
HTTP/2 200
date: Mon, 24 Jun 2019 10:11:39 GMT
content-type: text/html; charset=UTF-8
content-length: 1952
server: nginx
x-powered-by: Express
cache-control: public, max-age=0
last-modified: Tue, 21 May 2019 10:11:37 GMT
vary: Accept-Encoding
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
x-xss-protection: 1; mode=block;
accept-ranges: bytes
Ultimately, I don't want accept-ranges: bytes , instead it must be "accept-ranges: none"
I tried following in the nginx configurations
server {
.....
.....
.....
location / {
......
......
max_ranges 0;
proxy_force_ranges on;
......
}
}
What could be the possible issue ?
Did you tried removing "proxy_force_ranges on" ? It enables byte-range support for responses from the proxied server regardless of the “Accept-Ranges” field in these responses.
Related
I have a problem that relates to the authentication with the google.
I followed the tutorials and finally managed to reach google site where I can select the choose an account section. Then I select one and get redirect to the local address: https://localhost:44377/signin-google?state ...
but there I get:
An unhandled exception occurred while processing the request.
Exception: OAuth token endpoint failure: Status: Unauthorized;Headers: Cache-Control: max-age=0, private
Date: Sat, 10 Feb 2018 22:14:21 GMT
Transfer-Encoding: chunked
Accept-Ranges: none
Server: GSE
Vary: X-Origin, Origin, Accept-Encoding
WWW-Authenticate: Bearer realm="https://accounts.google.com/"
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Alt-Svc: hq=":443"; ma=2592000; quic=51303431; quic=51303339; quic=51303338; quic=51303337; quic=51303335,quic=":443"; ma=2592000; v="41,39,38,37,35"
;Body: {
"error": "invalid_client",
"error_description": "Unauthorized"
}
;
Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler+d__12.MoveNext()
Any help in investigating this would be very helpful.
Some (but not all) Google accounts consistently respond with a 401 when trying to access the Google Calendar API despite tokeninfo telling me the access token I'm using has the proper scope (see curl output below). I can successfully obtain a new access token using a refresh token, but the calendar api continues to 401.
Does anyone have an idea why this might be happening?
$ curl -v https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=[redacted]
* Trying 216.58.195.74...
* Connected to www.googleapis.com (216.58.195.74) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.googleapis.com
* Server certificate: Google Internet Authority G2
* Server certificate: GeoTrust Global CA
> GET /oauth2/v3/tokeninfo?access_token=[redacted] HTTP/1.1
> Host: www.googleapis.com
> User-Agent: curl/7.49.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: Mon, 01 Jan 1990 00:00:00 GMT
< Date: Tue, 18 Oct 2016 22:00:45 GMT
< Vary: X-Origin
< Content-Type: application/json; charset=UTF-8
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Alt-Svc: quic=":443"; ma=2592000; v="36,35,34,33,32"
< Accept-Ranges: none
< Vary: Origin,Accept-Encoding
< Transfer-Encoding: chunked
<
{
"azp": "[redacted].apps.googleusercontent.com",
"aud": "[redacted].apps.googleusercontent.com",
"sub": "[redacted]",
"scope": "https://www.googleapis.com/auth/plus.me https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/calendar",
"exp": "1476831626",
"expires_in": "3581",
"email": "[redacted]",
"email_verified": "true",
"access_type": "offline"
}
* Connection #0 to host www.googleapis.com left intact
$ curl -v https://www.googleapis.com/calendar/v3/users/me/calendarList?access_token=[redacted]
* Trying 216.58.195.74...
* Connected to www.googleapis.com (216.58.195.74) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.googleapis.com
* Server certificate: Google Internet Authority G2
* Server certificate: GeoTrust Global CA
> GET /calendar/v3/users/me/calendarList?access_token=[redacted] HTTP/1.1
> Host: www.googleapis.com
> User-Agent: curl/7.49.1
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Vary: X-Origin
< WWW-Authenticate: Bearer realm="https://accounts.google.com/", error=invalid_token
< Content-Type: application/json; charset=UTF-8
< Date: Tue, 18 Oct 2016 22:01:14 GMT
< Expires: Tue, 18 Oct 2016 22:01:14 GMT
< Cache-Control: private, max-age=0
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Alt-Svc: quic=":443"; ma=2592000; v="36,35,34,33,32"
< Accept-Ranges: none
< Vary: Origin,Accept-Encoding
< Transfer-Encoding: chunked
<
{
"error": {
"errors": [
{
"domain": "global",
"reason": "authError",
"message": "Invalid Credentials",
"locationType": "header",
"location": "Authorization"
}
],
"code": 401,
"message": "Invalid Credentials"
}
}
* Connection #0 to host www.googleapis.com left intact
I was able to reproduce the situation by creating a google apps user whose sub-organization has Google Calendar turned off. Google will still allow the user to grant calendar access and will indicate the scope has been granted but will 401 in the way described when you try to call any Google Calendar API endpoints with their access token.
Google, please make your error message clearer or prevent the initial scope grant when requesting access to an app that has been turned off by an administrator!
This was happening for my client, even with Google Calendar enabled.
Turns out they'd let the free 14 day trial expire, and hadn't entered a credit card for payment. Error disappeared once they'd sorted that.
I need to get the "uxfauthorization" tag value into a text box in ASP.NET. I am using curl to send the json request to server and getting below response from the server. I want "uxfauthorization" key value to be in text box so that user can view the authorization key.
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Date: Tue, 08 Dec 2015 15:16:45 GMT
Pragma: no-cache
Content-Length: 22
Content-Type: application/json
Expires: -1
SET-COOKIE:WIRELESS_SECURITY_TOKEN=HvsvzzAyux0oXBENeLPwtQ**___currentencryptionkey___36wByp bpGkrOz/CQ6pTbGt44O+PpWvB0gu8hr12vIYa32j2Qg3Na3eylq5h4dZLeAmA6T6kZ4hevGJUjqXeFN8 2DIyEdaO7MVEqiemiGB90F7J0KXfiUdRjw5E5XkV9a; path=/; HttpOnly;
uxf_lastLoginDate: 1449587736928
uxfauthorization:UXF_CSRFToken:csrfcurrentencryptionkey___dpU+veeOOvcV/0mrZKt3V8c4tI677cvo0hodpmXppOQ= UXF_SessionToken:HvsvzzAyux0oXBENeLPwtQ==___currentencryptionkey___36wBypbpGkrOz/CQ6pTbGt44O+PpWvB0gu8hr12vIYa32j2Qg3Na3eylq5h4dZLeAmA6T6kZ4hevGJUjqXeFN82DIyEdaO7MVEqiemiGB90F7J0KXfiUdRjw5E5XkV9a
X-XSS-Protection: 1; mode=block
X-Powered-By: Servlet/3.0 JSP/2.2
{"__EmptyObject__":{}}
Thanks In Advance.
You can use regular expression to parse the value from the text. It can be something like below:
String pattern = #"uxfauthorization:(.*?)";
Regex re = new Regex(pattern);
MatchCollection matches = re.Matches(your_curl_response_here);
foreach(Match match in matches){
// use the match.ToString() for your need
}
I am troubleshooting a problem with a WordPress front-end user login form. The code works great with the same site on a development server, but not on the production server.
On the production server, the authentication passes, and the wp_signon() returns a full user object, however the cookie is not being inserted into the response stream.
The following code demonstrates this:
$user = wp_signon( '', $secure_cookie );
var_dump($user);
When using Fiddler to sniff the packets, this is what is returned by the production server:
HTTP/1.1 302 Found
Server: cloudflare-nginx
Date: Fri, 24 May 2013 07:53:01 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Pingback: http://www.domain.com/blog/xmlrpc.php
X-Frame-Options: SAMEORIGIN
Location: http://www.domain.com/log-in/
Vary: Accept-Encoding,User-Agent
X-Cacheable: YES:FORCED
X-Varnish: 1753703763
Age: 0
Via: 1.1 varnish
X-Cache: MISS
CF-RAY: 73868e9b8da0418
Content-Length: 802
object(WP_User)#329 (7) {
["data"]=>
object(stdClass)#388 (10) {
["ID"]=>
string(2) "53"
["user_login"]=>
string(14) "SubscriberTest"
["user_pass"]=>
string(34) "$P$B8O8w6awJnKrHNoFLOyHJHfKiPE1nt/"
["user_nicename"]=>
string(14) "subscribertest"
["user_email"]=>
string(33) "SubscriberTest#domain.com"
["user_url"]=>
string(0) ""
["user_registered"]=>
string(19) "2013-05-23 05:56:42"
["user_activation_key"]=>
string(0) ""
["user_status"]=>
string(1) "0"
["display_name"]=>
string(14) "SubscriberTest"
}
["ID"]=>
int(53)
["caps"]=>
array(1) {
["subscriber"]=>
bool(true)
}
["cap_key"]=>
string(15) "wp_capabilities"
["roles"]=>
array(1) {
[0]=>
string(10) "subscriber"
}
["allcaps"]=>
array(3) {
["read"]=>
bool(true)
["level_0"]=>
bool(true)
["subscriber"]=>
bool(true)
}
["filter"]=>
NULL
}
The WordPress control panel login still works and the cookie is inserted when signing into the backend.
The production server is also using CloudFlare, but I am not sure if that could be related or not. I have sent a support ticket to Cloud Flare as well, hoping that they can confirm whether their proxy service might be stripping them off.
Here is what the response header portion looks like on my development server when running the same code. In this one you can see that the cookie is being sent:
HTTP/1.1 302 Found
Date: Fri, 24 May 2013 02:18:23 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: W3 Total Cache/0.9.2.11
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Pingback: http://domain.com/blog/xmlrpc.php
X-Frame-Options: SAMEORIGIN
Set-Cookie: wordpress_548d950a57c83d7fc5c2eb781062ef26=SubscriberTest%7C1369534704%7C08d4578ca9049beadffa39e0be0ea941; path=/blog/wp-content/plugins; httponly
Set-Cookie: wordpress_548d950a57c83d7fc5c2eb781062ef26=SubscriberTest%7C1369534704%7C08d4578ca9049beadffa39e0be0ea941; path=/blog/wp-admin; httponly
Set-Cookie: wordpress_logged_in_548d950a57c83d7fc5c2eb781062ef26=SubscriberTest%7C1369534704%7Cc41eb224ebec7f57982d0f93e70f7cff; path=/; httponly
Set-Cookie: wordpress_logged_in_548d950a57c83d7fc5c2eb781062ef26=SubscriberTest%7C1369534704%7Cc41eb224ebec7f57982d0f93e70f7cff; path=/blog/; httponly
Location: http://domain.com/
Vary: Accept-Encoding
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
I finally discovered that Varnish was running on the production server and it was stripping off the cookies. Once URL exclusions were added, the WP functions started working as expected.
I get an error when initializing a RavenDB documentstore that contains a machinename in the URL, combined with specifying a non default database i.e Multitenant.
I can only get store.Initialize() to work if I do not specify a default database.
My ConnectionString is http://somemachinename:8080;ResourceManagerId=d5723e19-92ad-4531-adad-8611e6e05c8b
Following code fails
var store = new DocumentStore
{
ConnectionStringName="RavenDB,
DefaultDatabase="TNW_Grc_CLient",
EnlistInDistributedTransactions=false
}
store.Initialize(); // fails with the following exception
with this message
Message = "Value cannot be null.\r\nParameter name: g"
Scenario:
a) The first time (if the database does not yet exist) this is called,
the call succeeds and I note that the raw http response is:
HTTP/1.1 201 Created
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Location: /docs/Raven/Databases/TNW_Grc_Client
Server: Microsoft-HTTPAPI/2.0
Raven-Server-Build: 427
Date: Fri, 26 Aug 2011 19:45:23 GMT
X-Charles-Received-Continue: HTTP/1.1 100 Continue
Expires: 0
Cache-Control: no-cache
{"Key":"Raven/Databases/TNW_Grc_Client","ETag":"00000000-0000-0300-0000-000000000001"}
b) The second time the call fails. Debugging some, it appears the etag header is not sent from
the server but is somehow expected by the client code:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Server: Microsoft-HTTPAPI/2.0
Raven-Server-Build: 427
Date: Fri, 26 Aug 2011 19:48:10 GMT
Expires: 0
Cache-Control: no-cache
{"Id":null,"Settings":{"Raven/DataDir":"~\\Tenants\\TNW_Grc_Client"}}
You can specify values on the connection string or on the document store properties, not both at the same time.