Internet Explorer buggy when accessing a custom weblogic provider - internet-explorer-8

I've created a custom Weblogic Security Authentication Provider on version 10.3 that includes a custom login module to validate users. As part of the provider, I've implemented the ServletAuthenticationFilter and added one filter. The filter acts as a common log on page for all the applications within the domain.
When we access any secured URLs by entering them in the address bar, this works fine in IE and Firefox. But when we bookmark the link in IE an odd thing happens. If I click the bookmark, you will see our log on page, then after you've successfully logged into the system the basic auth page will display, even though the user is already authenticated. This never happens in Firefox, only IE. It's also intermittent. 1 time out of 5 IE will correctly redirect and not show the basic auth window. Firefox and Opera will correctly redirect everytime. We've captured the response headers and compared the success and failures, they are identical.
final boolean isAuthenticated = authenticateUser(userName, password, req);
// Send user on to the original URL
if (isAuthenticated) {
res.sendRedirect(targetURL);
return;
}
As you can see, once the user is authenticated I do a redirect to the original URL. Is there a step I'm missing? The authenticateUser() method is taken verbatim from an example in Oracle's documents.
private boolean authenticateUser(final String userName, final String password, HttpServletRequest request) {
boolean results;
try {
ServletAuthentication.login(new CallbackHandler() {
#Override
public void handle(Callback[] callbacks)
throws IOException, UnsupportedCallbackException {
for (Callback callback : callbacks) {
if (callback instanceof NameCallback) {
NameCallback nameCallback = (NameCallback) callback;
nameCallback.setName(userName);
}
if (callback instanceof PasswordCallback) {
PasswordCallback passwordCallback = (PasswordCallback) callback;
passwordCallback.setPassword(password.toCharArray());
}
}
}
}, request);
results = true;
} catch (LoginException e) {
results = false;
}
return results;
I am asking the question here because I don't know if the issue is with the Weblogic config or the code. If this question is more suited to ServerFault please let me know and I will post there.
It is odd that it works everytime in Firefox and Opera but not in Internet Explorer. I wish that not using Internet Explorer was an option but it is currently the company standard. Any help or direction would be appreciated. I have tested against IE 6 & 8 and deployed the custom provider on 3 different environments and I can still reproduce the bug.

We figured it out.
The fix was to disable auth cookies on the weblogic server. For some reason Internet Explorer would lose the cookie causing Weblogic to think the session was being hacked. That is what prompted the basic auth login.
We still don't know what was causing IE to lose the cookie but this provider is for an intranet so the fix won't harm our overall security.
I hope this helps someone else.

Related

Google Drive SDK 1.8.1 RedirectURL

Is there any way to provide RedirectURL then using GoogleWebAuthorizationBroker?
Here is the sample code in C#:
Task<UserCredential> credential = GoogleWebAuthorizationBroker.AuthorizeAsync(secrets, scopes, GoogleDataStore.User, cancellationToken, dataStore);
Or we have to use different approach?
I have an "installed application" that runs on a user's desktop, not a website. By default, when I create an "installed application" project in the API console, the redirect URI seems to be set to local host by default.
What ends up happening is that after the authentication sequence the user gets redirected to localhost and receives a browser error. I would like to prevent this from happening by providing my own redirect URI: urn:ietf:wg:oauth:2.0:oob:auto
This seems to be possible using Python version of the Google Client API, but I find it difficult to find any reference to this with .NET.
Take a look in the implementation of PromptCodeReceiver, as you can see it contains the redirect uri.
You can implement your own ICodeReceiver with your prefer redirect uri, and call it from a WebBroker which should be similar to GoogleWebAuthorizationBroker.
I think it would be great to understand why can't you just use PrompotCodeReceiver or LocalServerCodeReceiver.
And be aware that we just released a new library last week, so you should update it to 1.9.0.
UPDATE (more details, Nov 25th 2014):
You can create your own ICodeReceiver. You will have to do the following:
* The code was never tested... sorry.
public class MyNewCodeReceiver : ICodeReceiver
{
public string RedirectUri
{
get { return YOU_REDIRECT_URI; }
}
public Task<AuthorizationCodeResponseUrl> ReceiveCodeAsync(
AuthorizationCodeRequestUrl url,
CancellationToken taskCancellationToken)
{
// YOUR CODE HERE FOR RECEIVING CODE FROM THE URL.
// TAKE A LOOK AT THE FOLLOWING:
// PromptCodeReceiver AND LocalServerCodeReceiver
// FOR EXAMPLES.
}
}
PromptCodeReceiver
and LocalServerCodeReceiver.
Then you will have to do the following
(instead of using the GoogleWebAuthorizationBroker.AuthorizeAsync method):
var initializer = new GoogleAuthorizationCodeFlow.Initializer
{
ClientSecrets = secrets,
Scopes = scopes,
DataStore = new FileDataStore("Google.Apis.Auth");
};
await new AuthorizationCodeInstalledApp(
new GoogleAuthorizationCodeFlow(initializer),
new MyNewCodeReceiver())
.AuthorizeAsync(user, taskCancellationToken);
In addition:
I'll be happy to understand further why you need to set a different redirect uri, so we will be able to improve the library accordingly.
When I create an installed application the current PromptCodeReceiver and LocalServerCodeReceiver work for me, so I'm not sure what's the problem with your code.

Phonegap Android app ajax requests to HTTPS fail with status 0

Ajax HTTPS requests from my PhoneGap/Cordova app on Android inexplicably fail with status=0. It appears only when signing the app with the release key (i.e., exporting from ADT), but doesn't appear when signing with debug key (running directly in emulator or phone).
request = new XMLHttpRequest()
request.open "GET", "https://some.domain/", true
request.onreadystatechange = ->
console.log "** state = " + request.readyState
if request.readyState is 4
console.log "** status = " + request.status
request.send()
always outputs
** state = 4
** status = 0
It doesn't matter if i install the app from Play Store or with adb utility. I presume it could be connected with the certificate, since not all HTTPS domains fail this way.
I was having the same problem but my solution was a little different.
In only the Android App build of my Cordova app, AJAX calls to my server via HTTPS were being blocked. Not in iOS, not in desktop browsers. Most confusingly, in the actual Android Browser the HTTPS AJAX calls would work no problem.
I verified that I could make HTTPS AJAX calls to well known and trusted URLs such as https://google.com as well as regular HTTP calls to any URL I cared to try.
This led me to believe that my SSL cert was either NOT installed 100% correctly OR the cheap (~$10 usd) cert from PositveSSL was not universally trusted OR both.
My cert was installed on my AWS Load Balancer so I looked around about how I may have messed this up and also how PositiveSSL was not the best cert to be using in terms of trustworthiness. Lucky me found an article covering AWS ELB installation of certs AND they happened to be using a PositiveSSL cert! Contained within was this little gem:
"...Don’t be fooled by the AWS dialog, the certificate chain isn’t really optional when your ELB is talking directly to a browser..."
http://www.nczonline.net/blog/2012/08/15/setting-up-ssl-on-an-amazon-elastic-load-balancer/
Drumroll....
I reinstalled the cert with the "optional" Certificate Chain info and voilà!, the HTTPS AJAX calls to my server started working.
So it appears that the Android Webview is more conservative than the Android Browser in terms of cert trust. This is not totally intuitive since they are supposed to be basically the same tech.
It happens when the requested URL responds with an erroneous or self-signed certificate. While testing or distributing the app to friends, setting <application android:debuggable="true"...> in AndroidManifest.xml is enough — it automatically bypasses certificate errors.
But Google Play Store will not accept an APK with android:debuggable="true". First of all, the certificates, of course, need to be fixed. But while that happens, here is a workaround for PhoneGap/Cordova 3:
In your app package create a subclass for CordovaWebViewClient:
public class SSLAcceptingCordovaWebViewClient extends CordovaWebViewClient {
public SSLAcceptingCordovaWebViewClient(CordovaInterface cordova, CordovaWebView view) {
super(cordova, view);
}
#Override
public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
handler.proceed();
}
}
Same for IceCreamCordovaWebViewClient:
public class SSLAcceptingIceCreamCordovaWebViewClient extends IceCreamCordovaWebViewClient {
public SSLAcceptingIceCreamCordovaWebViewClient(CordovaInterface cordova, CordovaWebView view) {
super(cordova, view);
}
#Override
public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
handler.proceed();
}
}
in <Your App Name>.java add an override for makeWebViewClient:
#Override
protected CordovaWebViewClient makeWebViewClient(CordovaWebView webView) {
if(android.os.Build.VERSION.SDK_INT < android.os.Build.VERSION_CODES.HONEYCOMB) {
return new SSLAcceptingCordovaWebViewClient(this, webView);
} else {
return new SSLAcceptingIceCreamCordovaWebViewClient(this, webView);
}
}
Et voilà! SSL errors will be disregarded. However, never use erroneous certificates. Try to fix them first and use this dirty workaround only when you run out of other solutions.
The other option that works as well is to recompile the underlying cordova.jar file so that the test is removed completely thus no reason to worry about your cert being valid or not. I ran in the issue due to the fact that Android would not recognize the GoDaddy cert that was on the server. The cert shows valid on iOS but even when browsing from Android complained about the cert. This is from the 2.9.x branch as this is what I was working with.
cordova-android / framework / src / org / apache / cordova / CordovaWebViewClient.java
#TargetApi(8)
#Override
public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
final String packageName = this.cordova.getActivity().getPackageName();
final PackageManager pm = this.cordova.getActivity().getPackageManager();
ApplicationInfo appInfo;
try {
appInfo = pm.getApplicationInfo(packageName, PackageManager.GET_META_DATA);
handler.proceed();
return;
/* REMOVED TO BY PASS INVALID CERT CHAIN ****
if ((appInfo.flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0) {
// debug = true
handler.proceed();
return;
} else {
// debug = false
super.onReceivedSslError(view, handler, error);
}*/
} catch (NameNotFoundException e) {
// When it doubt, lock it out!
super.onReceivedSslError(view, handler, error);
}
}
NOTE: I understand this is not safe but when all else fails this solved the issue that has been on going for over 2 months including reinstalling the cert following the cert chain install guide and beside it is a site that is our own not 3rd party so no matter if valid or not it is only connecting to this server.
In my case it has been a missing intermediate certificate, which I had to install on my webserver. You have to keep it in mind especially when you use cheap certificates.
You can check it easily online if your certificate chain is proper, you will find a lot on google, e.g. https://www.sslshopper.com/ssl-checker.html
At the Apache2 it's part of the VirtualHost 443 directive, you have three rules in your directive, it looks like that:
SSLCertificateFile /etc/apache2/ssl/mycert.crt
SSLCertificateKeyFile /etc/apache2/ssl/mykey.key
SSLCertificateChainFile /etc/apache2/ssl/certification_auth_intermediate.crt
You can't use relese-ready (phonegap) apks with self-signed certificates. Look at this answer to get further information.
lg
fastrde

IIS Express Returning HTTP 400 for WCF RESTful Service

I have a WCF RESTful Web Service (using webHttpBinding) that is returning a 400 when I try to call a web service method on it.
If I go to mywebservice.svc, I get the standard WCF web service page. But if I go to /mywebservice.svc/some/rest/service/url, I get an Http 400. Every single time. Doesn't matter the parameters, or the method being called.
Here's what we've looked at so far:
Looked at IIS Express logs. There is no Win32 status (i.e. status 0) to go along with the HTTP Status
Turned on WCF logging. Nothing is logged by WCF, which suggests the request isn't even making it that far.
Tried debugging our method, but the breakpoint never gets hit.
Tried running the service under Cassini. Same result (http 400).
Tried another user on the problematic machine. Same result.
We know that this works on other machines. The problematic machine is using VS 2010 on Win XP. We are using WCF 4.0
I know there isn't much to go on here because we don't have a specific error message, but given where we've looked, does anybody have any suggestions on where to look next?
UPDATE: Added Code Samples
Here is the definition of my with one method, and the implementation of that method.
[ServiceContract]
public interface IMAMDataWebService
{
[WebGet(UriTemplate = "/Contracts/{taxID}", ResponseFormat = WebMessageFormat.Json)]
[OperationContract]
ContractCollection Contracts(string taxID);
}
public ContractCollection Contracts(string taxID)
{
ContractCollection contracts = new ContractCollection();
try
{
contracts = _contractService.GetContracts(taxID);
}
catch (RstsException rEx)
{
if (!rEx.Logged)
_errorLogger.LogError(rEx);
WebFault.ThrowFault(rEx, HttpStatusCode.InternalServerError);
}
catch (Exception ex)
{
RstsException rEx = new RstsException(ex);
_errorLogger.LogError(rEx);
WebFault.ThrowFault(rEx, HttpStatusCode.InternalServerError);
}
if (contracts.Count == 0)
{
WebFault.ThrowFault(Strings.ObjectNotFound, HttpStatusCode.NotFound);
}
return contracts;
}
I'm calling it with a web browser, i.e. MAMDataWebService.svc/Contracts/123456789
I'm convinced this has to be a permissions problem, but I"m not sure what. It works on all our Win 7 machines using VS 2010, but a few users still have XP and they're the ones with the problem. But without any errors, it's hard to tell what's going on.

How to do HttpWebRequests from a Windows Phone 7?

I've been looking for an answer to my problem for several days, but sadly had no luck. I hope you guys here can help me out.
So, what I want to do is just a simple call against the delicious.com API that returns me the recent bookmarks ("posts" in delicious terminology). Therefore you simply use the following URI and enter your credentials for logging in to delicious.com.
When I do this from a standard .NET4 Console Application with the magic of HttpWebRequest and setting the Credentials, it works as expected. Trying to do the same basic HttpWebRequest on the WP7 emulator leads to an WebException stating that "The remote server returned an error: NotFound.".
When diving deeper into this exception I can see that my Response has a StatusDescription of "Unauthorized". It seems like no authentication happend at all.
Next I tried - as I read that setting the Credentials sometiemes leads to problems - was to directly set the "Authorization" RequestHeader. Guess what, the result was the same.
I ended up with the following code and without ideas. I hope, somebody here is able to
help me out and point a way, how I can reach my bookmarks from my WP7.
public void RetrieveRecentBookmarks(string userName, string password)
{
HttpWebRequest request = HttpWebRequest.CreateHttp(requestString);
byte[] bytes = System.Text.UTF8Encoding.UTF8.GetBytes(userName + ":" + password)
string authInfo = Convert.ToBase64String(bytes);
request.Headers[System.Net.HttpRequestHeader.Authorization] = "Basic " + authInfo;
RequestState state = new RequestState(request);
IAsyncResult result = request.BeginGetResponse(GetResponseCallback, state);
}
private static void GetResponseCallback(IAsyncResult asynchronousResult)
{
RequestState state = asynchronousResult.AsyncState as RequestState;
HttpWebRequest request = state.Request as HttpWebRequest;
// Here is where it breaks...
HttpWebResponse response = request.EndGetResponse(asynchronousResult) as HttpWebResponse;
}
Thanks in advance!
As I now know, my code is absolutely correct and working. What was not working was the Emulator communication, as already mentioned by Shawn Kendrot.
I set up a completely fresh Win7, installed the WP7.1 SDK (and 7.1.1 Update) and it works like expected. So it seems like something blocked my calls from the emulator. I've got no idea, what it was, but I must admit, I don't care too much as it is working now.
Thank you Shawn for pointing out that there are sometimes problems with the Emulator and the web, that kicked me into the right direction.

FBJS AJAX.post is not working after permissions dialog

I have problems with facebook application based on flash which communicate with PHP using FBJS-bridge. When someone use the application for the first time, he/she is asked for various permissions. After that, flash contact PHP with ajax but request is never sent. When you refresh page, everything is working without any problems.
If you remove the application on privacy settings, refresh the page and try again - same bug happens. If you allow application, refresh page, in other tab remove application and start application in previous tab - user is asked for permissions but everything is working after allowing application.
This is FBJS code
function openPermissions(){
Facebook.showPermissionDialog(/*permissions string*/, permissionOnDone);
}
function permissionOnDone(perms){
if (!perms) {
document.getElementById("indexswf").callSWF('noallow');
} else {
document.getElementById("indexswf").callSWF('allow');
}
}
function ajaxCall(url,parameters){
var params = {};
for(var i=0;i<parameters.length;i+=2){
params[parameters[i]]=parameters[i+1];
}
ajax = new Ajax();
ajax.requireLogin = true;
ajax.responseType = Ajax.RAW;
ajax.ondone = function(data){
document.getElementById("indexswf").callSWF('parseAjax', data);
}
ajax.post('http://the.url.to/the_real_server/not_to_the_fb_url/'+url,params);
}
openPermissions is called to display permission dialog, and on allow flash function allow() is called. In flash, allow() calls JS function ajaxCall(), which should make ajax request. But, ajax.post never sends request. I know that for sure, because flash function parseAjax was never called and also debugging tools in browsers are not showing any ajax requests. URL and parameters are same as when it is working. No flash or JS errors are detected...
Anyone have idea what is wrong here? Maybe facebook bug again since this was all working few days ago...
ajax.requireLogin = true should be set to false for some reason

Resources