I'm trying to access a site/servlet with a required authentication, which pops-up a window and ask for username and password. However when I try to access it through my "proxy servlet" I can't get the pop-up working although the client side gets this kind of HTTP response:
Cache-Control private
Content-Length 2429
Content-Type text/html;charset=ISO-8859-1
Date Mon, 02 Apr 2012 09:52:44 GMT
Expires Thu, 01 Jan 1970 07:30:00 SGT
Server Apache-Coyote/1.1
Set-Cookie JSESSIONID=039823E2FAB18C59C9B351F2C6B1909E; Path=/manager/; HttpOnly
WWW-Authenticate Basic realm="Tomcat Manager Application"
Isn't it when client (browser) gets response like this with WWW-Authenticate it will show a popup?
Browser should receive status code 401 (as in this basic authentication example) to present the pop-up window to the user. It won't work with 200 or any other status code in spite of WWW-Authenticate header.
Related
I need to get events\log for all activities done by admin and other office365 users such as user login, user logout, create user, delete, Update
I have successfully configured office 365 management activity API and also receiving responses for following Content Type
Audit.AzureActiveDirectory
Audit. Exchange
Audit.SharePoint
DLP.All (DLP events only for all workloads)
But for Audit.General Content Type I am receiving Empty response please help me to solve this problem?
Do the Audit.General API provides the admin and users activities log.
If not in what ways I can get these logs, please advise.
Responce for Audit.General`
--> GET https://manage.office.com/api/v1.0/a153759e-c827-46b8-8223-7ceb5c246c3f/activity/feed/subscriptions/content?contentType=Audit.General http/1.1
User-Agent: java-tutorial
client-request-id: e77e2404-666b-4898-85bb-afa1d2da0cae
return-client-request-id: true
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlZXVkljMVdEMVRrc2JiMzAxc2FzTTVrT3E1USIsImtpZCI6IlZXVkljMVdEMVRrc2JiMzAxc2FzTTVrT3E1USJ9.eyJhdWQiOiJodHRwczovL21hbmFnZS5vZmZpY2UuY29tIiwiaXNzIjoiaHR0cHM6Ly9zdHMud2luZG93cy5uZXQvYTE1Mzc1OWUtYzgyNy00NmI4LTgyMjMtN2NlYjVjMjQ2YzNmLyIsImlhdCI6MTUwMTg0MDcwMSwibmJmIjoxNTAxODQwNzAxLCJleHAiOjE1MDE4NDQ2MDEsImFjciI6IjEiLCJhaW8iOiJZMkZnWUJCeWZpRjF3Q0R6eitjMVNrR0pvaXVkWHF5L2QzaFZxTlpHeitjR1VabHp0UElCIiwiYW1yIjpbInB3ZCJdLCJhcHBpZCI6ImZhNThlYWY5LWRhNDMtNGNkYS1hYjQwLTU4MTY2MGMxYjNjMCIsImFwcGlkYWNyIjoiMSIsImZhbWlseV9uYW1lIjoiTmF2YWxlIiwiZ2l2ZW5fbmFtZSI6IkF2aW5hc2giLCJpcGFkZHIiOiI0OS4yNDguNzcuMTQiLCJuYW1lIjoiQXZpbmFzaCBOYXZhbGUiLCJvaWQiOiI2ZWMzMjRhZS0wNzhiLTRmYWEtYTQ0NC0yNmNlZDVhNDA1ZjAiLCJwbGF0ZiI6IjMiLCJwdWlkIjoiMTAwMzNGRkZBMzJDMjg4NiIsInNjcCI6IkFjdGl2aXR5RmVlZC5SZWFkIEFjdGl2aXR5RmVlZC5SZWFkRGxwIEFjdGl2aXR5UmVwb3J0cy5SZWFkIFNlcnZpY2VIZWFsdGguUmVhZCBUaHJlYXRJbnRlbGxpZ2VuY2UuUmVhZCIsInN1YiI6InY4NDdtVzl5em5wSFBIdV9La1RPdDZNblJUMUIzODZuODl0NFlLYVp5VGciLCJ0aWQiOiJhMTUzNzU5ZS1jODI3LTQ2YjgtODIyMy03Y2ViNWMyNDZjM2YiLCJ1bmlxdWVfbmFtZSI6ImF2aW5hc2huQExlb1RlY2hub3NvZnQub25taWNyb3NvZnQuY29tIiwidXBuIjoiYXZpbmFzaG5ATGVvVGVjaG5vc29mdC5vbm1pY3Jvc29mdC5jb20iLCJ2ZXIiOiIxLjAifQ.EV6j1KkH8jC6CSdnbXSPh5fT-cLxaiQiVCorOi3ljGaTJYfq6xyyTsE3nJNgq2DziHIAXKoAZkaHMu8RUZBEqhYplgvTeAdstWt-RVziJKgAFXX5jIYvZExZbnJVZDXtBr2BIgfy0rhx5sWY-XFz27VzK9bmPl2IWpLstWZ1w7N8VyBNLssGwwL_rYwjBcDqon4F-u7Xas6DyYSfkvZyMpJ3kbbAb2KK3Rmo-d2LdUfz2aF6j02u6VgmHsBNPahD8iB3KDihzWYiujAlT2OY5UrNHO1MxIGnyBod9ejmQK87FjYyJEuoRZM6b65QKUcaOTaamK-ZjJKItkEpYs-I_g
--> END GET
<-- 200 OK https://manage.office.com/api/v1.0/a153759e-c827-46b8-8223-7ceb5c246c3f/activity/feed/subscriptions/content?contentType=Audit.General (163ms)
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 2
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
X-Powered-By: ASP.NET
Date: Fri, 04 Aug 2017 10:03:25 GMT
OkHttp-Sent-Millis: 1501841286505
OkHttp-Received-Millis: 1501841286668
[]
<-- END HTTP (2-byte body)`
Currently I am working on Office 365 Management Activity API and I also faced this scenario earlier. This API was released by Microsoft merely within one year and it is in growing stage only. However, I would strongly recommend you to raise ticket to Microsoft support from your Office 365 admin portal. Microsoft support team will contact and assist you getting your problem resolved.
I try to create a session connecting an Android phone to a Java backend.
For this I call an url looking like this: https://sub.domain.com/path-web/rest/user/init
HTTP/1.1 302 Found
Location: https://path.domain.com;jsessionid=SOMEID.frontend2
Content-Type: text/plain; charset=UTF-8
Content-Length: 0
Connection: close
Set-Cookie: JSESSIONID=SOMEID.frontend2;
Path=/; Secure; HttpOnly
Date: Fri, 24 Oct 2014 08:32:17 GMT
This causes my http library, in this case okhttp to try to follow the redirection to https://path.domain.com;jsessionid=SOMEID.frontend2.
This now fails because parsing this url with java.net.URI produces an URI with a null host.
Also Chrome want open the url at it is.
Is the url created wrong from the backend or is the parsing of the url wrong in java.net.URI?
What can I do to work with urls like that?
As described in the comments. The url is not valid and therefore not parsed from java.net.URI.
How do I handle properly a client Connection: close request field? As of now if I get this particular field I close the socket and wait for a following request from the client than reply again and start serving the data.
I don't know why my client/server communication is not working as the Apache Server I tested with.
Thanks for any clarifications...
Client/Server comunication:
CLIENT:
HEAD /stream.mpeg HTTP/1.0
Host: 127.0.0.1
User-Agent: SuperPlayer
Connection: Close
SERVER:
HTTP/1.0 200 OK
Date: Wed, 1 Jun 2011 20:05:13 GMT
Server: HTTP Server
Last-Modified: Mon, 06 Aug 2009 01:02:23 GMT
Accept-Ranges: bytes
Connection: Close
Content-Type: audio/mpeg
CLIENT:
HEAD /stream.mpeg HTTP/1.0
Host: 127.0.0.1
User-Agent: SuperPlayer
Connection: Close
SERVER:
HTTP/1.0 200 OK
Date: Wed, 1 Jun 2011 20:05:13 GMT
Server: HTTP Server
Last-Modified: Mon, 06 Aug 2009 01:02:23 GMT
Accept-Ranges: bytes
Connection: Close
Content-Type: audio/mpeg
231489172304981723409817234981234acvass123412323
21312hjdfaoi8w34yorhadl4hi8rali45mhalo3i,wmotw
345fqw354aoicu43yocq2i3hr
Client/ApacheServer Comunication:
CLIENT:
GET /test.mp3 HTTP/1.0
Host: 192.168.1.120
User-Agent: SuperPlayer
Connection: Close
SERVER:
HTTP/1.1 200 OK
Date: Wed, 01 Jun 2011 19:15:11 GMT
Server: Apache/2.2.16 (Win32)
Last-Modified: Thu, 29 Apr 2010 21:06:34 GMT
ETag: "14000000047049-4f75c8-4856680636a80"
Accept-Ranges: bytes
Content-Length: 5207496
Connection: close
Content-Type: audio/mpeg
...d.....<).0.. ..........<.#.. ( .h.$.J...1...i....A. ......c....a.9..!g.N...A. ........ ....>......|.......8....a......|..|N.............'>........?...C.....#..TJt.n .e...r.iL..#..IH...pR|.
Yes closing the socket is the right action to take. If the client is using this header properly, they are closing the socket on their end once they receive your response.
What I'm noticing here is that your server is not returning a Content-Length header. Even though the client is issuing a HEAD request, based on the W3C proposal (sec. 9.4):
The metainformation contained in the HTTP
headers in response to a HEAD request
SHOULD be identical to the information
sent in response to a GET request.
This method can be used for obtaining
metainformation about the entity
implied by the request without
transferring the entity-body itself.
This method is often used for testing
hypertext links for validity,
accessibility, and recent
modification.
The response to a HEAD request MAY be
cacheable in the sense that the
information contained in the response
MAY be used to update a previously
cached entity from that resource. If
the new field values indicate that the
cached entity differs from the current
entity (as would be indicated by a
change in Content-Length, Content-MD5,
ETag or Last-Modified), then the cache
MUST treat the cache entry as stale.
The key here is to make sure you're telling the client the size of the response without actually sending the data.
The Connection: close header just means that the client is expecting you to close the connection after sending the response. That also absolves you of having to send a Content-Length: header.
May I ask why are you using http 1.0 in the request?
There were no persistent connections in http 1.0, so the server is supposed to terminate the TCP connection after the response, whether you send Connection: close or not.
If you are using HTTP 1.0, there is no persistent connections as alexrs pointed, instead, Connection: keep-alive is being used with HTTP 1.0. On HTTP 1.1, you do not need that because HTTP connections are persistent by default on HTTP 1.1.
8.1.2 Overall Operation
A significant difference between HTTP/1.1 and earlier versions of HTTP
is that persistent connections are the default behavior of any HTTP
connection. That is, unless otherwise indicated, the client SHOULD
assume that the server will maintain a persistent connection, even
after error responses from the server.
Persistent connections provide a mechanism by which a client and a
server can signal the close of a TCP connection. This signaling takes
place using the Connection header field (section 14.10). Once a close
has been signaled, the client MUST NOT send any more requests on that
connection.
You can take a look at to the HTTP 1.1 RFC;
RFC for HTTP 1.1
I have java application running under tomcat which is fronted by apache webserver.
In my code I set cookie domain as
.example.com
but still my cookies shows up under www.example.com instead of under example.com in the client browser. What is so strange google analytics cookies shows up under example.com but my own code cannot store cookies under example.com?
Apache server is setup such that requests for example.com shows up as www.example.com in the client browser address bar if that is related to the issue ? I do need this otherwise different session id are generated for example.com and www.example.com which is bad for my applicaton.
Apache server is setup such that
requests for example.com shows up as
www.example.com in the client browser
address bar if that is related to the
issue ?
I am not 100% sure, but this looks like the root of the problem. How does Apache make the client browser to display www.example.com instead of example.com? Most probably, by redirecting each request for example.com to www.example.com. When the browser processes redirection, it sends a request for www.example.com and from that point on thinks that it is working with www.example.com.
Now, what happens when there is a Set-Cookie in the response header? It will obviously treat it as coming from www.example.com. There is no way a browser would allow such cookie to set its domain to .example.com because it would be a security problem. Imagine that mysite.somefreehosting.com sets a cookie for the domain .somefreehosting.com. Then someothersite.somefreehosting.com would receive this cookie which may lead to a lot of trouble. The standard specifies that such cookie should be rejected, but I wouldn't be surprised if some browsers are smart enough to handle such cases and to treat .example.com as www.example.com.
To be sure, I recommend that you check what exactly your site sends to the browser by sending a request with something like lwp-request script. You'll see what redirections are happening and what headers are actually set in the response, like this:
alqualos#ubuntu:~$ lwp-request -sSed http://google.com/
GET http://google.com/ --> 301 Moved Permanently
GET http://www.google.com/ --> 302 Found
GET http://www.google.co.il/ --> 200 OK
Cache-Control: private, max-age=0
Connection: close
Date: Sat, 18 Dec 2010 18:54:57 GMT
Server: gws
Content-Type: text/html; charset=windows-1255
Content-Type: text/html; charset=windows-1255
Expires: -1
Client-Date: Sat, 18 Dec 2010 18:54:57 GMT
Client-Peer: 173.194.37.104:80
Client-Response-Num: 1
Set-Cookie: PREF=ID=368e9cfd56643257:FF=0:TM=1292698497:LM=1292698497:S=s-Jur84NgaNH5Mzx;
expires=Mon, 17-Dec-2012 18:54:57 GMT; path=/; domain=.google.co.il
Set-Cookie: NID=42=bZ6goDV_b2MiWlTMONwiijaON5U_TBGB2_yNheonEwA1GVLU77EhyfUhk9Wvj70xTFrpvGy4s_aBp1UZtvRRnsnYjacjz_UVx0_iSr9R3nYXMyRtwkS5qV98_Egb16pZ;
expires=Sun, 19-Jun-2011 18:54:57 GMT; path=/; domain=.google.co.il; HttpOnly
Title: Google
X-XSS-Protection: 1; mode=block
I want to fetch a web page from a ASP.NET site that is only accessible from within a session. I'm using Apache HttpClient. I first open the main page of the site, then I search for the link to the "goal" page, and then I fire up a GET request for the "goal" page. The problem is that when I get the response for the second GET request, I always get the same (first) page. If I open the site with Firefox or Google Chrome I get the "goal" page.
From the first response from the server I get the following headers:
HTTP/1.1 200 OK
Date: Sun, 12 Dec 2010 19:03:56 GMT
Server: Microsoft-IIS/6.0
Platform: Mobitel Pla.NET
Node: 4
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Set-Cookie: ASP.NET_SessionId=0vpgd055cifko3mnw4nkuimz; path=/
Cache-Control: no-cache, must-revalidate
Content-Type: text/html; charset=utf-8
Content-Length: 7032
I inspected the traffic with WireShark and all headers look OK. I send the correct cookie back to the server on the second GET request.
I'm using Apache HttpClient. I have only one instance of DefaultHttpClient and I reuse that for the second request. I have BROWSER_COMPATIBILITY Cookie Policy.
Any ideas?
You need send back this header from the client (send back the cookie you received) in all your further requests:
Cookie: ASP.NET_SessionId=0vpgd055cifko3mnw4nkuimz; // and all other cookies
That should do the trick
I found my stupid mistake.
The mistake was that I was sending the second GET request to a link, without replacing the ampersand character codes.
Ex:
/(0vpgd055cifko3mnw4nkuimz)/Mp.aspx?ni=1482&pi=72&_72_url=925b9749-b7c7-4615-9f1a-9b613c344c82
That is wrong, because I send & instead of &
The RIGHT way to do it is:
/(0vpgd055cifko3mnw4nkuimz)/Mp.aspx?ni=1482&pi=72&_72_url=925b9749-b7c7-4615-9f1a-9b613c344c82