Sometimes Microsoft does something so stunningly dumb that it makes my head hurt. Help me find out it's really not the case ... please!
I've got an issue with the login page of an ASP.NET (3.5) site I'm developing whereby IE (7 or 8 ... can't bear to open 6) doesn't offer to save the password when a user logs in. I've checked other browsers and Firefox, Chrome and Safari all offer to save the password just fine. I've also confirmed that IE password saving on my test boxes is is working OK on other sites and for e.g. Google etc it works fine.
The searching I've done has turned up very little, but what little it did turn up seems to suggest that IE won't offer to save a password if the form on the page contains more than two text controls. That's the case with my form which also has controls to allow a user to register. And when I remove these additional controls, IE magically prompts to save password, so this does seem to be true.
Now ... if ASP.NET would allow me to have multiple forms, all would be well and I would be able to separate out the two functions into standalone forms and IE would prompt to save passwords. But, ASP.NET doesn't allow me to do this as it only allows a single form. I could fudge a non runat=server form in there and try to do this, but guess what? Because my page uses a MasterPage, any form tag I add is automatically stripped out, even if it's a non runat=server form.
So, I don't see any way around this without fundamentally changing what I was trying to achieve. It looks like I have to explain to my users that they won't be prompted to have their passwords saved if they use IE (a Microsoft product) because I developed my site with ASP.NET (err ... a Microsoft product).
If this is so, I just can't get over how head-smackingly ridiculous this is. If anyone can offer any ideas on how to get around it, can tell me I've got it all wrong and am a big, stupid idiot myself, or just wants to confirm that it's not just me that thinks this is monumentously dumb, then please, please do so.
Just for the record, I really don't want to (and don't see why I should have to) compromise my design and split my pages in two (which will result in a worse experience for the user).
#Chris That's what I went for in the end.
So for the benefit of anyone else, I still have my activation controls in a runat=server form and process these in the code for that page. Then I have a second, standard HTML form with HTML input textfields that posts to a different .NET page. This deals with the users login. I pick up the values in this page via Request.Form and deal with the login from here.
Upsides:
It all works and users get their logins remembered as they would expect to.
Downsides:
I lost the ability to use a MasterPage (as I need two forms in the page) so I effectively have had to duplicate the template - I don't like this much.
If the users login is invalid or causes some kind of error, I have to redirect to the initial page and pass it a flag to get it to show a relevant error message - I don't like this much either.
Like I say, though, it just works and in this case that's what was most important. Thanks for your input.
Related
there is this site https://www.delinski.at/ and it has a nice form where you can pick some values from dropdowns like Date, Number of Persons etc., and then submit the form. It redirects and I see the values on the redirected page link as parameters (if I have changed the defaults).
I searched for and tried several Form Plugins which all do not seem to work - most recent one (Form Maker) lets me design the form as I want but at the end I realized when I click on Submit, the values are not transfered to the target page (confirmed by Form Maker Support as work as intended). It's confusing because actually that should be a basic funciontality of a HTML form, right?
So I want to know if there are plugins where I can get a similar look&feel like the example given above.
That site is a Static Site Generated framework not WordPress. That site would also be very expensive to build cause that is all coded, and very well:)
You are not actually seeing a form there at all that is just how PHP natively uses the URL to navigate via a button.
Almost all the form plug ins for WP use the database write now and do not pass the parameters of the entered form as a php _ POST with a redirect.
I kind of think what you really are looking for is a faceted search feature
One of the best that comes to my mind is https://facetwp.com/demo/cars/?_vehicle_type=truck
Notice the car icons those are actually search buttons:) Of course you will have to build a template to do that neat stuff on the SSG site you linked but...
here is a really informative write upon how it works to get started.
I am working locally on an ASP.NET site and am experiencing problems with postbacks in IE8.
I have a page with a repeater that builds a table and each row has a LinkButton on it that is used to delete that row.
In FireFox and Chrome, the button works as expected - the forms posts back and all the values from the form are available for processing. In IE8, the form posts back but the forms collection is empty, except for the button that initiated the postback.
This is a problem because
it's odd and I don't understand and
I use the values from the posted back form to rebuild some business objects (I don't store them in viewstate or session but rebuild them from scratch based upon values input by user in form). When I post back from FF/Chrome, the full form is there (e.g. Request.Form.AllKeys has, say, 60 items) and I can derive the values for my business object. When I post back from IE, my form is practically empty and my rebuilding code fails (e.g. Request.Form.AllKeys has, say, only 9 items instead of the expected 60).
I am at a loss to explain why there is this difference in the contents of the form collection upon postback between FF/Chrome and IE and would greatly appreciate any insight/help in this regard.
I've tried to break the issue down as I see it - if any further info is required, please let me know. Thanks for your help.
Your problem sounds unusual and is not something I've ever come across. Whilst I can't help directly, I'd recommend using Fiddler - Web Debugging Proxy to examine the HTTP traffic as a means to diagnosing what is going on. To quote, "Fiddler is freeware and can debug traffic from virtually any application, including Internet Explorer, Mozilla Firefox, Opera, and thousands more..."
Solved this - turns out I had a form nested within the main form on my master page. Removed it and all is well.
We had similar problem in IE8 in Windows 2008 and the solution was related to User Right escalations.
On Windows 2008 Machine I had to go to:
Start > administrative Tools > Local Security Policy > Local Policies > Security Option
then select "User Account Control : Admin Approval Mode for Build-in Administrator account"
Select Enable & then Apply.
Thanks
Anugrah
I'm bulding an ASP.NET website just to test my skills, and I'm using lots of callbacks that doesn't require a page refresh, and the URL doesn't change. In this example, assume I'm bulding a web-based Outlook with a treeview, a grid, and a detail pane.
Is there a standard (published or assumed) that says I should postback, or even update my URL from time to time?
The Standard you are probably looking for is called usability. DHTML, Ajax, or whatever you want to call it is fine until it breaks the users expectation of browser behavior. When the back button fails to work, and users can't bookmark the page exactly as they expect, you're doing it wrong.
I don't know about an official standard, but you may want to check out Gmail to see a good example of how something similar was done. The URL changes on the site much more often than the page refreshes.
I'm trying to figure out a logical and quick way to implement the "PRG" design style in a small site I'm doing, and I'm finding an issue I can't think of a good way to solve.
I have a form. It has 2 fields (first and last name). When the user submits the form, I check to make sure that they have data in them before I save it to the database. If they do not, then I show them a nice little error message and leave what little they have entered still in the form.
However, in order to correctly implement PRG, as I understand it, I would have to validate on postback, determine there is an error, then redirect the user to the same page but via get, not post, which would then eliminate any kind of scary message "you are about to resubmit the contents of a form to the server, which can have unintended consequences..." etc if the user reloaded the page.
How can I redirect the user back to the same page and still save their already entered values in the form fields?
I mean, I could pass all the values in the Querystring, but for complex forms this would become very difficult and messy. I could store the values in Session, but that would still be messy, and a good way to bring a webserver to its knees on a busy site.
What do you, my fellow web programmers, do?
As you note, by redirecting, you will lose the data they have entered unless you go through some QueryString gyrations. You are really defeating one of the nice features of asp.net by doing this - the form values are all preserved for you, so that if the page needs to be redisplayed after a post with errors, most of the work is done for you. Why do you want to use a PRG design? What benefit do you expect to get that standard asp.net form handling doesn't give you?
I have a web application that I use Login Control and ASP.net membership for Sign in process.
my application work propebly untill last week I upload new version, in this version I didnt change the login UC and just the main page ( default page after user logged in ) changed.
but some users report me they cant login and redirect to Login page.
some note:
1- this problem occure just in IE browser
2- users that report this problem can login to old version
I add a log procedure and see users redirected becuase of this code
if (!this.User.Identity.IsAuthenticated)
{
Response.Redirect("~/Secure/Signin.aspx");
}
I checked and see this.User.Identity.Name was empty or null.
What setting maybe changed?
Thanks
I've seen a similar thing happen when there was a malformed FORM tag was rendered inside my ASP.Net Server FORM tag. By 'malformed' I mean that it was missing the required METHOD attribute.
It is my understanding that the HTML spec doesn't support nested FORM tags, so different browsers handle them differently. In my case, I saw a similar issue as you describe, with no issues in Firefox, and major issues in IE.
Check to ensure there are no Nested FORM tags on your page. Also check all FORM tags to ensure they have all required attributes.
Doubt this will solve the problem, it's kind of tangental. But, rather than hand coding the redirect url it's poosible to use
FormsAuthentication.RedirectToLoginPage()
which has the benefit of taking care of the returnUrl and stuff. It'd require the login Url set in the web.config.