S
Sky
Hi all,
Problem:
A minority of users using an embdedded IE control in a WinForms app cannot
log-in to our secure (HTTPS) website which uses and ASP.Net V2 Forms
authentication. After entering there username and password then pressing
submit, the page refreshes and blanks the form details though details are
valid. Incorect details show correct error message. Users going to the URL
directly still have the same problem outside of the WinForms using IE, but it
works fine in Firefox.
Background:
Firstly, I've done a lot of searching on the web trying to find a solution,
and referred our customers to a whole host of possible solutions, including
direct cookie control but none seem to work. A lot of the posts out there end
with no solutions given!
Whist the majority of our customers can log-in, inc. all of us in-house and
therefore unable to replicate the problem (v. annoying!), some customers have
filed bug reports detailing the above problem. Since these reports don't
filter to the dev until later, and I have limited, if any access to our live
sites and logs, it's very difficult for me to trace the problem at the
correct time! The only time I have seen a problem similar is when the machine
name included an _ (underscore)
Platform:
The details given show that it occurs on a variety of platforms e.g. IE6 or
IE7,
Windows 2003, XP, Vista, 32bit, 64bit. There is no common thread, never
Firefox.
One customer has reported the log-in failed on their 64bit machine but their
32bit machine in the same room worked fine.
Fix Attempts:
Posted a thread with instructions on enabling cookies, clearing cache, given
direct URL to log-in to, created a very simple forms log-in page none of
which worked.
Code:
Below is the simple test log in code, it just calls a webservice with the
page details and processes the result. This all works fine. It is the
Redirect that seems to be the issue.
protected void LoginButton_Click(object sender, EventArgs e)
{
if (ValidateUser(UserName.Text.Trim(), Password.Text))
FormsAuthentication.RedirectFromLoginPage(UserName.Text, true);
else
LoginError();
}
public bool ValidateUser(string username, string password)
{
if (FragObject == null)
return false;
string ResultMsg = string.Empty;
// webservice call
MsgResult result =
FragObject.WebLogin(username,password,WebUtility.RequestIP);
if (!result.IsSuccess || FragObject.SessionId == null)
{
CheckResultError(result, "FragObject.WebPlayer.WebLogin", true);
ResultMsg = result.Message;
return false;
}
return result.IsSuccess;
}
Web.config has
<authentication mode="Forms">
<forms loginUrl="~/Login.aspx" defaultUrl="default.aspx"/>
</authentication>
There is also a Membershipprovider setting but this is not used in the test
login.
Ideas:
I can second guess that it's more of a client configuration issue than a
code issue since most users don't have a problem and we have tested on
several platforms in-house. What this issue might be I dont know, I've really
ran out of ideas hence this post!
I would be most grateful if anyone can offer some suggestions. One of the
biggest problems I face is not being able to have a user who has this problem
at the end of the phone...so it's a very hit and miss affair.
I hope this includes enough information!
Kindest Regards
Sky
Problem:
A minority of users using an embdedded IE control in a WinForms app cannot
log-in to our secure (HTTPS) website which uses and ASP.Net V2 Forms
authentication. After entering there username and password then pressing
submit, the page refreshes and blanks the form details though details are
valid. Incorect details show correct error message. Users going to the URL
directly still have the same problem outside of the WinForms using IE, but it
works fine in Firefox.
Background:
Firstly, I've done a lot of searching on the web trying to find a solution,
and referred our customers to a whole host of possible solutions, including
direct cookie control but none seem to work. A lot of the posts out there end
with no solutions given!
Whist the majority of our customers can log-in, inc. all of us in-house and
therefore unable to replicate the problem (v. annoying!), some customers have
filed bug reports detailing the above problem. Since these reports don't
filter to the dev until later, and I have limited, if any access to our live
sites and logs, it's very difficult for me to trace the problem at the
correct time! The only time I have seen a problem similar is when the machine
name included an _ (underscore)
Platform:
The details given show that it occurs on a variety of platforms e.g. IE6 or
IE7,
Windows 2003, XP, Vista, 32bit, 64bit. There is no common thread, never
Firefox.
One customer has reported the log-in failed on their 64bit machine but their
32bit machine in the same room worked fine.
Fix Attempts:
Posted a thread with instructions on enabling cookies, clearing cache, given
direct URL to log-in to, created a very simple forms log-in page none of
which worked.
Code:
Below is the simple test log in code, it just calls a webservice with the
page details and processes the result. This all works fine. It is the
Redirect that seems to be the issue.
protected void LoginButton_Click(object sender, EventArgs e)
{
if (ValidateUser(UserName.Text.Trim(), Password.Text))
FormsAuthentication.RedirectFromLoginPage(UserName.Text, true);
else
LoginError();
}
public bool ValidateUser(string username, string password)
{
if (FragObject == null)
return false;
string ResultMsg = string.Empty;
// webservice call
MsgResult result =
FragObject.WebLogin(username,password,WebUtility.RequestIP);
if (!result.IsSuccess || FragObject.SessionId == null)
{
CheckResultError(result, "FragObject.WebPlayer.WebLogin", true);
ResultMsg = result.Message;
return false;
}
return result.IsSuccess;
}
Web.config has
<authentication mode="Forms">
<forms loginUrl="~/Login.aspx" defaultUrl="default.aspx"/>
</authentication>
There is also a Membershipprovider setting but this is not used in the test
login.
Ideas:
I can second guess that it's more of a client configuration issue than a
code issue since most users don't have a problem and we have tested on
several platforms in-house. What this issue might be I dont know, I've really
ran out of ideas hence this post!
I would be most grateful if anyone can offer some suggestions. One of the
biggest problems I face is not being able to have a user who has this problem
at the end of the phone...so it's a very hit and miss affair.
I hope this includes enough information!
Kindest Regards
Sky