I've a custom webserver which parses HTTP requests including multipart-form data.
In case of following, things are good:
<FORM method = "POST" action = "#" enctype multipart form-data multiple>
<INPUT type = "file"/>
<INPUT type = "submit"/>
</FORM>
The above HTML sends request which look like:
POST / HTTP/1.1
Host: 192.168.1.2:8888
User-Agent: Shockwave Flash
Connection: Keep-Alive
Cache-Control: no-cache
Accept: text/*
Content-Length: 884
Content-Type: multipart/form-data; boundary=----------------------------1193f8fd031d
img 1
----------------------------1193f8fd031d
img 2
----------------------------1193f8fd031d--
In case I use uploadify as per its docs, I donot get similar HTTP request at the backend.
How can I view HTTP request which uploadify sends?
On the server you can install Wireshark or try using fiddler on the client-side to view the HTTP communication.
Related
I have a CORS-enabled Spring Boot API that runs on Google Cloud Run and a Vue.js front end that runs on Firebase and uses Axios to make the calls to the back end.
The Problem is that when the front end wants to access the back end (Browser --> Google Clud), it fails with:
Access to XMLHttpRequest at 'https://<backend>' from origin 'https://<frontend>' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
If I access from LOCAL front end (also Browser) to a LOCAL back end, it works: The error above is not shown in the Browser console and I get the data).
If I make the OPTIONS or GET call from Postman to the Google Cloud back end, it works.
I noticed, that with Postman I need to include the Authorization header in the OPTIONS request to send the Bearer token to Google to make it work. The Browser does not send any Authorization header in the OPTIONS call, even if I add withCredentials: true to the Axios config like this:
const response = await axios({
method: 'post',
withCredentials: true,
url: 'https://<backend>',
headers: {
'Authorization': 'Bearer ' + gCloudToken
},
data: {
// data...
}
});
Isn't that a security problem, to send the token in the header? I mean, everyone can see the headers and then fake a call to the server.
Can anybody show how to send the Authorization header in the OPTIONS call via Axios or tell how to correctly handle this problem?
UPDATE 1:
The request from the browser looks like this:
OPTIONS /path/to/api HTTP/2
Host: <backend>-ew.a.run.app
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization,content-type
Referer: https://frontend.web.app/
Origin: https://frontend.web.app
Connection: keep-alive
And this is the response:
HTTP/2 403 Forbidden
date: Tue, 07 Jul 2020 23:57:27 GMT
content-type: text/html; charset=UTF-8
server: Google Frontend
content-length: 320
alt-svc: h3-29=":443"; ma=2592000,h3-27=":443"; ma=2592000,h3-25=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
X-Firefox-Spdy: h2
As you can see, no CORS headers (like e.g. access-control-allow-origin) are present.
The cause of this issue is that by not allowing unauthenticated calls the CORS preflight are always rejected with a 403 error message.
There is already a feature request for Cloud Run in orther to support CORS and authentication with Cloudrun.
The Workaround I would see so far is to allow unauthenticated calls on the CloudRun and implement the authentication on your code, However this can have security disadvantages.
I have a SOAP b2b web service to consume. I'm trying to understand the basic elements of the call and eventually consume it without an app.config / wsdl import and will be using c#.
I imported the wsdl to SOAP UI entered some dummy values for the request data and typed in the password to the request properties. I returned a 500 error, details restricted to local machines.
1 strange aside properties say Authentication Type: No Authorization but without the correct credential I do get a 401.
The Raw SOAP UI Call
GET https://b2b.example.com/yyyb2b/zzz.asmx HTTP/1.1
Host: b2b.example.com
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: "http://www.example.com/yyy/GDDA"
Content-Length: 424
Host: b2b.example.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
So I tried to replicate the call in fiddler to see if I could get any better information:
The headers there:
POST /yyyb2b/zzz.asmx HTTP/1.1:
Host: b2b.example.com
Content-Type: text/xml; charset=utf-8
Content-Length: 419
SOAPAction: "http://www.example.com/yyy/GDDA"
Authentication: Basic base64(username:Password)
Fiddler returns a 302 (found) and then a 400 saying bad request - Invalid Header
I tried removing POST /yyyb2b/zzz.asmx HTTP/1.1: as the 'bad header' and got redirected to sign into the gui portion of the web app. The other possible difference I see is the method of authentication.
Why am I getting different errors?
I am currently working on development of a caldav synchronization server layer for my calendar application. I am able to answer all the initial requested by the calendar client and currently stuck with the REPORT method.
When PROPFIND is done on Calendar, it asks for CTag and Sync-Token. I do answer this query by providing a CTag and Sync-Token (currently to mock the server, I dynamically generate these value and serve the client).
In the next query, the requested method is REPORT on the calendar as shown below:
Request from client:
REPORT URI /users/admin%40a.de/calendar/ PROTOCOL HTTP/1.1
----------------------------------------
Accept-encoding gzip, deflate
Accept */*
Connection keep-alive
Prefer return=minimal
Host **************
Brief t
User-agent Mac+OS+X/10.10.5 (14F27) CalendarAgent/316.1
Depth 1
Authorization Basic YWRtaW5AYS5kZTpwYXNz
Accept-language en-us
Content-type text/xml
Content-length 260
Request body: <?xml version="1.0" encoding="UTF-8"?>
<A:sync-collection xmlns:A="DAV:">
<A:sync-token>http://calserver.org/ns/sync-token/1</A:sync-token>
<A:sync-level>1</A:sync-level>
<A:prop>
<A:getcontenttype/>
<A:getetag/>
</A:prop>
</A:sync-collection>
Response from the Server:
Response header
Content-type: text/calendar; charset=UTF-8
Connection: keep-alive
Date Thu, 17 Dec 2015 19:35:40 GMT
Transfer-encoding chunked
Http/1.1 207 Multi-Status
Response body
<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<D:multistatus xmlns:D=\"DAV:\" xmlns:C=\"urn:ietf:params:xml:ns:caldav\" xmlns:E=\"urn:ietf:params:xml:ns:carddav\">
<D:response>
<D:propstat>
<D:href>/calendar/2601ddd19c1001.ics</D:href>
<D:prop>
<D:getcontenttype>text/calendar</D:getcontenttype>
<D:getetag>"334411222s12"</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Now my question is, In the server-response, I answer the REPORT method that a new event has been created by providing a new ETag value, but the data is not requested by the Client ??
How and when should I serve the calendar data of the new event and what would be the request from client ???
Content-type should not be text/xml, It should be text/calendar.
The etag needs to be surrounded by double-quotes.
I'm pretty sure it's a bad idea to use a + in the uri the way you did. If you want to encode a space, use %20 instead, but it's probably even better to completely avoid any sort of special encoding.
The response to a sync-collection report also must have the current sync-token in the response body. See https://www.rfc-editor.org/rfc/rfc6578#section-6.4
Rather confused by the multiple edits but the content-type in the response header should definitely be text/xml
Content-type: text/xml; charset=UTF-8
Can somebody tell me how to add asp.net cookie authorization to a request header (via MVC3)?
Cookie:
Cookie: __RequestVerificationToken_Lw__=8+WZPGAaKtgkIPfbBovP1ZRP2qQKE3u67ueltnzcoCPH0nN1tUHdtgUorjlweUvn+zTJhkFeRuMShCOrbyHR5Xi3DOL4HCspXuVEOsWIr4Ape+l5MYPiFsQ6Lnw8LstqNjceWW9EaV24eA0mVxq2xTG18h/INNKLB8cRUiEn9DI=; .ASPXAUTH=C64A69436A8FC4A6DF5BC222982030C3CCF9E43FBCE335A47173236B4BA4B1CE762CBE6C9E9FDBB035D46C8F36228A61117F22DD55CF787D5E23A728F68B49DDF1A5D70FF3D33C8D16B06FC81894201E86DF93754B6021C9031CB4FBC5236DED952FB7244CE3217B659325A0614763B2E123002E5291EE8D8CEA7B2D7441F3EBB8176A71CDD6FEF3E545CDF46858174451D38890861664A55AF681A36C0B7CF1
Snippet of actual request:
Accept: text/*
Content-Type: multipart/form-data; boundary=----------KM7Ij5Ij5ei4gL6KM7ae0cH2Ef1ae0
User-Agent: Shockwave Flash
Host: localhost:82
Content-Length: 36874
Connection: Keep-Alive
Pragma: no-cache
Cookie: __RequestVerificationToken_Lw__=8+WZPGAaKtgkIPfbBovP1ZRP2qQKE3u67ueltnzcoCPH0nN1tUHdtgUorjlweUvn+zTJhkFeRuMShCOrbyHR5Xi3DOL4HCspXuVEOsWIr4Ape+l5MYPiFsQ6Lnw8LstqNjceWW9EaV24eA0mVxq2xTG18h/INNKLB8cRUiEn9DI=; .ASPXAUTH=C64A69436A8FC4A6DF5BC222982030C3CCF9E43FBCE335A47173236B4BA4B1CE762CBE6C9E9FDBB035D46C8F36228A61117F22DD55CF787D5E23A728F68B49DDF1A5D70FF3D33C8D16B06FC81894201E86DF93754B6021C9031CB4FBC5236DED952FB7244CE3217B659325A0614763B2E123002E5291EE8D8CEA7B2D7441F3EBB8176A71CDD6FEF3E545CDF46858174451D38890861664A55AF681A36C0B7CF1
------------KM7Ij5Ij5ei4gL6KM7ae0cH2Ef1ae0
<more stuff here...>
You don't. Cookies are automatically provided on each request when the cookie is set.
You set the cookie using FormsAuthentication class. Typically, this looks something like this:
FormsAuthentication.SetAuthCookie(model.UserName, false /*createPersistentCookie*/);
I have the following situation:
The browser does a POST with a Json payload to my server endpoint
My server processes the data and then issues a redirect to a new location
The browser does the redirect, but it does it with the same headers as the original post which mean it arrives at my endpint such that my endpoint
thinks it is a json request.
-> I want the redirect to arrive at my server as a standard text/html request.
Is it possible to control the headers that the redirect uses so that the Get request arrives with text/html Accept headers?
Here are some snippets from fiddler to highlight what I am talking about:
Initial POST, json payload:
POST /App/Client/Index HTTP/1.1
Accept: application/json, text/plain, */*
X-Requested-With: XMLHttpRequest
The response:
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
The subsequest GET request from the Redirect:
GET /App/Client/SingleEntity?entityId=f859a6ca-dbcf-49cf-8de0-3888b7011815 HTTP/1.1
Accept: application/json, text/plain, */*
X-Requested-With: XMLHttpRequest
I had a similar requirement. My solution was to not send a redirect, but a "200 OK" with the following JSON:
{"url": "http://example.com/redirect/to/some/resource"}
The client used the URL and redirected via Javascript, i.e. location.href = data.url. It might not be the answer you're looking for but it solves your problem...
See also: How to manage a redirect request after a jQuery Ajax call