CORS Error on POST with no content - rest

I have a controller-style REST web service endpoint which will work from the browser if I POST non-empty content, but when the content is empty, the browser returns:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. The response had HTTP status code 403. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Here is a request with content that works:
POST /my/controller/resource HTTP/1.1
Host: localhost:8083
Connection: keep-alive
Content-Length: 1
accept: application/json
Origin: null
Authorization: Bearer JWT
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
Content-Type: application/json
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
HTTP/1.1 204 No Content
Server: Apache-Coyote/1.1
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
Content-Language: en-US
Date: Thu, 15 Feb 2018 13:44:53 GMT
And here is a request without content that does not work
POST /my/controller/resource HTTP/1.1
Host: localhost:8083
Connection: keep-alive
Content-Length: 0
accept: application/json
Origin: null
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
Authorization: Bearer JWT
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
HTTP/1.1 403 Forbidden
Server: Apache-Coyote/1.1
Content-Type: text/plain
Content-Length: 0
Date: Thu, 15 Feb 2018 13:42:16 GMT
Can anyone shed some light on why the request without content is not working - and what I might do to correct this?

This doesn't appear to be a CORS error - the server is set up to not allow a zero-content-length POST request. That's what's throwing the 403 error response.

Related

Click on item Hide Icon dont refresh screen

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

Keycloak: ERR_TOO_MANY_REDIRECTS

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.

JSTree bug with ngnix

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?

Azure Rest API PUT Block Blob Returns "The specified resource does not exist." CORS

I am trying to upload a file to Azure Blob storage.
For some reason when I try to put a new block blob on in the storage it tells me the resource does not exist. I am sure it is something silly I am missing.
According to the documentation:
The Put Blob operation creates a new block blob or page blob, or updates the content of an existing block blob.
Updating an existing block blob overwrites any existing metadata on the blob. Partial updates are not supported with Put Blob; the content of the existing blob is overwritten with the content of the new blob. To perform a partial update of the content of a block blob, use the Put Block List (REST API) operation.
CORS is setup and that seems okay.
When I do a preflight and get this:
Request URL:https://<account>.blob.core.windows.net/test/image.png
Request Method:OPTIONS
Status Code:200 OK
Request Headers
-----------------
OPTIONS /test/image.png HTTP/1.1
Host: <account>.blob.core.windows.net
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Access-Control-Request-Method: PUT
Origin: http://www.<site>.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36
Access-Control-Request-Headers: accept, content-type
Accept: */*
Referer: http://www.<site>.com/azure/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Response Headers
----------------
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: Blob Service Version 1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 0d372e95-1524-460a-ab9c-7973d42a7070
Access-Control-Allow-Origin: http://www.<site>.com
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Headers: accept, content-type
Access-Control-Max-Age: 36000
Access-Control-Allow-Credentials: true
Date: Thu, 27 Feb 2014 22:43:52 GMT
But when I make the PUT request these are the results.
Request URL:https://<account>.blob.core.windows.net/test/image.png
Request Method:PUT
Status Code:404 The specified resource does not exist.
Request Headers
-----------------
PUT /test/image.png HTTP/1.1
Host: <account>.blob.core.windows.net
Connection: keep-alive
Content-Length: 22787
Cache-Control: no-cache
Pragma: no-cache
x-ms-blob-content-disposition: attachment; filename = "image.png"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36
Content-Type: image/png
x-ms-blob-type: BlockBlob
Accept: application/json, text/plain, */*
x-ms-version: 2013-08-15
Origin: http://www.<site>.com
x-ms-date: Thu, 27 Feb 2014 23:19:19 GMT
Referer: http://www.<site>.com/azure/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Response Headers
----------------
HTTP/1.1 404 The specified resource does not exist.
Content-Length: 223
Content-Type: application/xml
Server: Blob Service Version 1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: d5a60c8b-356a-44ff-93af-0ea720b5591f
x-ms-version: 2013-08-15
Access-Control-Expose-Headers: x-ms-request-id,Server
Access-Control-Allow-Origin: http://www.<site>.com
Access-Control-Allow-Credentials: true
Date: Thu, 27 Feb 2014 23:22:42 GMT

Network unreachable: robots.txt unreachable

I'm getting error "Network unreachable: robots.txt unreachable" when trying to add my website on Google Webmaster tools -> http://www.hyponomist.com/
You can check my robots.txt at here and sitemap.xml at here
I have reading other posts here and there, but could not solve/understand. what is causing this issue. Also, I tried downloading a page with the Fetch as Googlebot tool but got same error.
Anyone knows?
Thanks in advance!
Your web server is returning a 503 error when the user-agent string says the request is from Googlebot, but 200 when it's from a browser. If you use an http diagnostic tool such as Fiddler (http://fiddler2.com/) you can see this.
If you use Fiddler to send the same request that a browser would send:
GET http://www.hyponomist.com/robots.txt HTTP/1.1
Host: www.hyponomist.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.72 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
The response is:
HTTP/1.1 200 OK
Server: nginx/1.4.4
Date: Fri, 10 Jan 2014 21:34:42 GMT
Content-Type: text/plain; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Retry-After: 18000
Last-Modified: Fri, 10 Jan 2014 20:43:28 GMT
Content-Encoding: gzip
If you change the user-agent to mimic Googlebot:
GET http://www.hyponomist.com/robots.txt HTTP/1.1
Host: www.hyponomist.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Then the response is:
HTTP/1.1 503 Service Temporarily Unavailable
Server: nginx/1.4.4
Date: Fri, 10 Jan 2014 21:35:25 GMT
Content-Type: text/html; charset=iso-8859-1
Content-Length: 234
Connection: keep-alive
Retry-After: 18000
Exactly why it's doing this, I can't tell you. 503 is normally the error sent when a server is temporarily overloaded, but that's clearly not the case here. Maybe your firewall is poorly configured, and has blacklisted Googlebot based on request frequency? Take a look at your firewall settings and your server config.
Removing the trailing slash (use http://www.hyponomist.com instead of http://www.hyponomist.com/) may help