Can anyone please guide me how to fetch request.getHeader("referer") in HTTPS mode?
Currently it is returning null.
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3
Related
I write a java program like I saw here
How to read the https page content using java?
but for some sites the code does not work.
I got Error Server returned HTTP response code: 403 for URL: https://research.investors.com/stock-quotes/nyse-sailpoint-tech-holdings-sail.htm
It works for
url = "https://maven.apache.org/guides/mini/guide-repository-ssl.html";
Can someone help me ?
403 HTTP status stands for "Forbidden", most likely investors.com can check your request headers and deny the resource.
Try modifying the request headers using an User-Agent that site might accept.
403 Forbidden
The request contained valid data and was understood by the server, but the server is refusing action. This may be due to the user not having the necessary permissions for a resource or needing an account of some sort, or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed). This code is also typically used if the request provided authentication by answering the WWW-Authenticate header field challenge, but the server did not accept that authentication. The request should not be repeated.
So probably website, which you want to scrape, just restricted requests like yours (i mean requests, that was made not from browser).
But you can try Selenium.
OK , I solved.
I use con.setRequestProperty and set "User-Agent", "Accept", "Content-Type", "Accept-Language".
Thank you.
I am new to Windows authentication and am facing a weird issue.
I have setup an application with SPNEGO filter library for Java.
All settings as per the documentations have been set.
Now when i open the URL of my application from another machine in the same domain, using any browser, i get a negotiation header as
TlRMTVNTUAABAAAAl4II...
This means that it is an NTLM negotiation request.
if i start fiddler and then try to run the same request for testing, i am getting a kerberos authentication request.
YIIGgwYGKwYBBQUCoIIGdzCCBnOgMDAuBg...
This means that when I am calling using fiddler, the browser is assuming that the system is on same network.
I am unable to figure out why this is happening..??
I need the kerberos ticket even in normal execution.
Server: JBoss 4.3.2 GA
anybody has any idea...??
thanks in advance
I am getting this error in chrome:
The page at 'https://www.SERVER_ONE.com/' was loaded over HTTPS, but
requested an insecure XMLHttpRequest endpoint
'http://SERVER_TWO.com/someAPI'. This request has been blocked; the
content must be served over HTTPS.
Both SERVER_ONE, and SERVER_TWO are owned by me.
But the problem is that the HTTPS certificate I hold is only for server_ONE.
Is there anything I can do to resolve this error, can I introduce some mode_proxy in SERVER_TWO to redirect all https to http, or is there any way in which I can write some proxy in java side and put it on server_one which can act as an adapter for https to http?
Please guide me with some snippet code if any such adapter code is possible.
You should not call directly SERVER_TWO, you should configure or implement a proxy on SERVER_ONE so that every call can be done over HTTPS.
Just enable https on server2 and change your call from http to https.
For the certificate you can use https://letsencrypt.org/ for server2 for free.
Experts, I am not sure if this has been explained earlier, but what is the role of "realm" in client perspective, specially for digest authentication.
e.g Server has following information
realm : myrealm
username: username1
password : somePassword.
Authentication schema : Basic.
Now when client makes a call with header "Authorization : Basic "base64encoded_username:password", then request is successful.
How should client make use of "realm" in Http headers so that in case server has multiple realm, then server validates user ONLY against that realm.
Same doubt is for Digest authentication. Do we really need to include realm in http header we prepare for Authoriation: Digest?
I do not want to use HttpClient here.
After reading further, I figured out that client need not pass realm in request. When client sends a request to server, server challenges back to client with an response header e.g WWW-Authenticate: Basic realm="WallyWorld"Ref. This information is used e.g by browser as well and they pop up a dialog with message "server says WallyWorld" which is realm name. Client has to supply userid/password for that realm
I'm trying to implement SSO on an intranet application we are developing. I am using SPNEGO for this. Now I'm having some trouble configuring the SSO and hope someone here is able to help me.
The setup is like this:
Linux server with tomcat to serve the intranet application
Windows Server 2008 as domain controller (Active Directory)
Windows 7 client with IE9 and Firefox
When I open the intranet application I see a GET request going from the client to the tomcat server. The first response of the tomcat server and the SpnegoFilter is a 401 unauthorized which is right, cause the client needs to be authenticated.
806 6.117724 192.168.65.50 192.168.65.50 HTTP 284 HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate\r\n
The response of the client then is a GET request with a flag NTLMSSP_NEGOTIATE. Here it breaks. I don't expect a NTLM response, but a kerberos/spnego response. Somehow I just can't figure out how to send the correct response to the tomcat server.
808 6.123277 192.168.65.50 192.168.65.50 HTTP 637 GET / HTTP/1.1 , NTLMSSP_NEGOTIATE
By default NTLM isn't supported by SPNEGO so I get the following entry in my log:
java.lang.UnsupportedOperationException: NTLM specified. Downgraded to Basic Auth (and/or SSL) but downgrade not supported.
So I'm doing something wrong, but aftert a day fiddling with configurations and policies I just can't figure out what it is.
Hoping for some response.
Kerberos does not work on IPs, use fully qualified domain names.
Have you registered the SPN and is the client domain joined? The WWW-Authenticate: Negotiate will tell the web browser to try kerberos. The browser hands of that request to the OS (SSPI) based on URL in the address bar. There must be a SPN in AD for the URL. As others noted above, using an IP in your URL is more complicated, but can be done. If your client is not domain joined, there is extra config work to get it to contact your AD KDC. Firefox takes extra setup as well. Solve ths with IE, to eliminate that and them come back to FF when the issue is resolved.