Has anyone used Glassfish 3.1.2 with HTTP DIGEST authentication in anger?
I got it to work fine, or so I thought... until I discovered that its behavior was erratic...
it works maybe 9 out of 10 times, but fails to authenticate the 10th time.
This is when I test it with wget as a client on the same machine with the same credentials and the same Java EE application, (as it happens, a REST web service, but I also have the problem on other Applications.)
I ran wget locally.
My Glassfish machine is only servicing those wget requests, it isn't doing much else!
I've no reason to believe wget is misbehaving occasionally. I calculated the request digest by hand (from the wget HTTP debug) on one of the occasions that it failed, just to be sure. It seemed fine.
When I run wget with debug, I can see it failing first time without credentials, then
succeeding with credentials. However, 1 time in 10 or thereabouts it fails the 2nd time
too ( debug shown here.)
[writing POST file request.xml ... done]
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 401 Unauthorized
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition
3.1.2 Java/Sun Microsystems Inc./1.6)
Server: GlassFish Server Open Source Edition 3.1.2
WWW-Authenticate: Digest realm="jdbc-realm",qop="auth",nonce="1377101691098:d07adb4a1421a265f3aa36bd99df7f6ef8c7a6e7887eb7d876e6b5ce079d1126",
opaque="C26EED99B0A8C0BCA16900215CCD241F"
Content-Type: text/html
Content-Length: 1069
Date: Wed, 21 Aug 2013 16:14:50 GMT
---response end---
401 Unauthorized
Skipping 1069 bytes of body: [<!DOCTYPE html P...
I set debug for javax.enterprise.system.core.security.level=FINE
I didn't see any error messages... but I did notice that for a "good" wget, the "hasResourcePermission" was called 3 times, 2 times returning false and one time returning true.
However, for the "bad" wget call, it is only called 2 times returning false.
|FINE|glassfish3.1.2|javax.enterprise.system.core.security|_ThreadID=36;_ThreadName=Thread->2;
ClassName=com.sun.enterprise.security.web.integration.WebSecurityManager;
MethodName=hasResourcePermission;|[Web-Security] hasResource isGranted: false|#]
|FINE|glassfish3.1.2|javax.enterprise.system.core.security|_ThreadID=36;_ThreadName=Thread-
2;ClassName=com.sun.enterprise.security.web.integration.WebSecurityManager;
MethodName=hasResourcePermission;|[Web-Security] hasResource isGranted: false|#]
GOOD CASE ONLY
|FINE|glassfish3.1.2|javax.enterprise.system.core.security|_ThreadID=36;_ThreadName=Thread-
2;ClassName=com.sun.enterprise.security.web.integration.WebSecurityManager;
MethodName=hasResourcePermission;|[Web-Security] hasResource isGranted: true|#]
Any ideas anyone ? Is there more Debug I could enable ?
thanks
******************GLASSFISH DIGEST INSTRUCTIONS********
Install a mysql database with yum.
Follow these instructions (with some changes, this blog is for FORM authentication so stop at step 4)
http://jugojava.blogspot.ie/2011/02/jdbc-security-realm-with-glassfish-and.html
Create the mysql database "realm_db" with the tables in the above blog
Using the Glassfish console UI, I created a JDBC Connection Pool and JDBC Resource for mysql database.
In the Pool Additional Properties, add in your mysql database properties as shown in the blog
On the server-config, Security page, I set "Default Realm" to jdbc-realm
IMPORTANT: When creating the JDBC security realm, use JAAS context of "jdbcDigestRealm" and JNDI of "jdbc/realm_db".
I left these fields blank, Digest Algorithm, Encoding, Charset, Password, Encryption Algormithm etc. and I put the passwords in the mysql database in clear text.
By the way, I used an up-to-date version of wget for testing because I read somewhere that older versions don't have proper RFC2617 DIGEST support. The version is 1.14 from Aug 12.
you need a driver file in $GLASSFISH_HOME/domains/domain1/lib. The file is called mysql-connector-java-3.1.13-bin.jar
Related
I'm testing TMS WEB Core 2 and DMVC 3.2.2 (latest) on Delphi 11.2 by me test machine locally.
I've created a simple DMVC server with all default's setup through the wizard nothing fancy except added the CORS option.
I've created a TMS Web core project with all default's setup as well with a WebHttpRequest and WebMemo components.
I ran the DMVC server and can get the result beautify on the browser.
I ran the TMS Web core project to send a request to the server using
WebHttpRequest which is like this:
WebHttpRequest1.URL := 'http://localhost:8080/api/test';
WebHttpRequest1.Execute(
procedure(AResponse: string; AReq: TJSXMLHttpRequest)
begin
WebMemo1.Lines.Add(AResponse);
end
);
However I got this error:
ERROR
HTTP request error #http://localhost:8080/api/test | fMessage::HTTP request error #http://localhost:8080/api/test fHelpContext::0
at http://localhost:8000/Project1/Project1.js [263:50]
and the browser developer console shows:
Access to XMLHttpRequest at 'localhost:8080/api/test' from origin 'localhost:8000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header has a value 'localhost:8080' that is not equal to the supplied origin.
I want to send a request from the client to the server and get the respond in the WebMemo..
I've checked online to find that it's a backend-end problem, and some say its related to CORS, So How can I enable the CORS on server side using DMVC?
Your configuration prevents the client from connecting.
Both the server name and the port must match the CORS rule. To fix this, change the CORS header to a matching value.
This could be
Access-Control-Allow-Origin: http://localhost
or
Access-Control-Allow-Origin: http://localhost:8000
Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
I'm having trouble to open AWS dynamoDB shell (UI). Did anyone tried and worked?
Steps taken:
Download latest - https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.DownloadingAndRunning.html
Start local dynamodb - No Errors
run aws dynamodb list-tables --endpoint-url http://localhost:8000 - No Errors (shows the table)
Error:
When trying to access -> http://localhost:8000/shell i am getting HTTP 400 Request must contain either a valid (registered) AWS access key ID or X.509 certificate.
Ref for shell (UI) https://aws.amazon.com/blogs/aws/sweet-treats-for-dynamodb-users/
Note: I'm having aws cli setup with named profiles. I even tried http request in browser after exporting AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY,AWS_DEFAULT_REGION and still get above HTTP 400 error
This appears to be a bug in new versions DynamoDB Local, but I couldn't find any documentation about it being deliberate, so please try reporting it to Amazon...
I just checked version 1.13.5 from 2020-10-13, and the "/shell" works as expected and documented. But on version 1.18.0 from 2022-1-10, it doesn't - and reports the same error you listed:
HTTP/1.1 400 Bad Request
Date: Thu, 13 Jan 2022 08:06:18 GMT
Content-Type: application/x-amz-json-1.0
x-amzn-RequestId: 4f040110-4464-48dc-99c1-9b843c25db5f
Content-Length: 173
Server: Jetty(9.4.18.v20190429)
{"__type":"com.amazonaws.dynamodb.v20120810#MissingAuthenticationToken","Message":"Request must contain either a valid (registered) AWS access key ID or X.509 certificate."}
The release notes in DynamoDB Local doesn't mention anything about the shell being deliberately disabled.
You are not the first person to notice this problem - see also this question from two weeks ago:
Dynamodb local web shell does not load
I am using MSXML6 in a vbscript-like code to download data over HTTP. But the server now requires connections to upgrade to HTTPS.
This is causing the xmlhttp object to fail with the error "msxml6.dll: Access is denied."
Set http = CreateObject("msxml2.xmlhttp.6.0")
http.open "Get", URL, False 'false is for 'async'
http.send
Using a sniffing tool, the operation stops after receiving the redirection-to-https response, and the error is generated without further details.
Requesting http://host/doc.php (plain http), the returned headers look something like this:
HTTP/1.1 301 Moved Permanently
Date: Fri, 19 Jul 2019 23:59:30 GMT
Content-Type: text/html; charset=iso-8859-1
Transfer-Encoding: chunked
Connection: keep-alive
Location: https://host/doc.php
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
However, if the requested URL is already https, the operation resumes normally without any complaint.
Is there anything I can do on the server side to convince xmlhttp to upgrade the connection to https peacefully?
Updating the code in the client application is out of the question as it is a legacy application with so many users out there using it, without an update mechanism.
Asking the users to update the URL adding an "s" after http is workable but too much hassle, as reaching them to tell them is also not easy at all.
Edit:
The conclusion is in this comment. The summary is that this is a client-side protection feature and it cannot be overridden from the server side.
The problem as mentioned in Xmlhttp request is raising an Access Denied error is you need to use the Server version of XMLHTTP that isn't restricted to accessing sites trusted by IE and restricted by the IE security policies. This is because XMLHTTP is designed for client-side whereas ServerXMLHTTP is specifically designed for server-side usage.
I wanted to have digest authentication Authorization header added in very http request and hence added HTTP Authorization Manager under thread group. I added URL,username, password, domain, realm (both to same name) and selected BASIC_DIGEST as the option (I wanted only digest authentication).
I also uncommented http.authentication.preemptive$Boolean=true in httpclient.parameters and uncommented httpclient.parameters.file=C:\apache-jmeter-2.12\apache-jmeter2.12\bin\httpclient.parameters in jmeter.properties file.
After done, I closed my jmeter and started it again. When I gave a run and did a wireshark capture, I figured out that GET was sent with NO Authorization header, and server sends a 401 response and jmeter closes socket and fails the case.
I am not sure what I have done wrong. Awaiting for your comments.
JMeter Logs:
2014/11/20 13:19:35 INFO - jmeter.threads.JMeterThread: Thread started: Thread Group 1-1
2014/11/20 13:19:35 INFO - org.apache.commons.httpclient.auth.AuthChallengeProcessor: digest authentication scheme selected
2014/11/20 13:19:35 INFO - org.apache.commons.httpclient.HttpMethodDirector: No credentials available for DIGEST 'users#perf.tb.com'#192.168.100.30:80
Realm should not be required for digest authentication, domain is quite enough
Make sure that you're using either HttpClient3.1 or HttpClient4 implementation
See Windows Authentication with Apache JMeter guide for details on how to configure HTTP Authorization Manager for digest and kerberos authentication types
I'm trying to read my stock portfolio into a script. The following works with NAB Online Trading but not Bell Direct.
install the Export Domain Cookies Firefox addon
log in to my online broker with Firefox
save the domain cookies to a file (eg cookies.txt)
wget --no-check-certificate --load-cookies=cookies.txt -O folio.htm https://...(portfolio URL)
-- The idea being to reuse the browser's login session. When I try it with Bell Direct, wget is redirected to the login page. I get the same results with curl. What am I missing? Is there some state that is stored in the browser besides in the cookies? Bell isn't using "basic authentication" because the login page is a form for username / password - it doesn't pop up the browser's built-in login dialog.
Here is what happens (under Windows XP with Cygwin):
$ wget --server-response --no-check-certificate --load-cookies=cookies-bell.txt -O folio-bell.htm https://www.belldirect.com.au/trade/portfoliomanager/
--2009-12-14 10:52:08-- https://www.belldirect.com.au/trade/portfoliomanager/
Resolving www.belldirect.com.au... 202.164.26.80
Connecting to www.belldirect.com.au|202.164.26.80|:443... connected.
WARNING: cannot verify www.belldirect.com.au's certificate, issued by '/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Server CA/emailAddress=server-certs#thawte.com':
Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response...
HTTP/1.1 302 Found
Connection: keep-alive
Date: Sun, 13 Dec 2009 23:52:16 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Location: /account/login.html?redirect=https://www.belldirect.com.au/trade/portfoliomanager/index.html
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 229
Location: /account/login.html?redirect=https://www.belldirect.com.au/trade/portfoliomanager/index.html [following]
...
Perhaps the server is validating the session based on User-Agent as well as the cookie. Check what user-agent your Firefox install is using (perhaps use WhatIsMyUserAgent.com if you don't know it), and try using that exact same user agent in your Wget call (via the --user-agent="..." parameter).
You need to POST the login form variables, then, with those cookies, goto the inner page.
http://www.trap17.com/index.php/automatic-login-curl_t38162.html for some example code.
The login is encrypted over the HTTPS protocol, and you do not provide a certificate. Perhaps belldirect requires a valid certificate for client authentication.
You can export a certificate in Firefox by clicking the highlighted blue portion of the URL > More Information > Security Tab > View Certificate > Details > Export. Then, you can use the --certificate=filename option to specify the exported certificate in your wget command.
Maybe you need to set the referrer too.