ASP.NET 4.0 Web Forms app.
User logs in and normally link URLs look like this:
https://domain.com/directory/Page.aspx
On occassion ALL links for the user will be rendered with a whole bunch of extra text in the form:
https://domain.com/(F(194_random_characters_Here)/Services/directory/page.aspx
Odd thing is, the links still work. Once it starts happening for a given user, nothing short of an app pool recycle will fix it, and even then sometimes the user also has to clear their browser cache before the extra text goes away. We've seen it occur in several versions each of Firefox, Chrome and IE.
It's almost like the ~ portion of paths/links are getting the extra text added to them somehow.
It looks like you have cookieless sessions enabled.
Look in your web.config or IIS configuration for disabling cookieless sessions.
Related
I am debugging a web form application using Microsoft Visual Studio. Normally there are a number of pages displayed, starting with default.aspx, in sequence after certain buttons have been pressed on each. The default page has been set to default.aspx.
When I start the application using the debugger it brings up the third page in the sequence rather
than starting at default.aspx.
Is some information being stored in the background that influences which pages are presented first?
Check the web tab of your project. During working and debugging, I MUCH perfer that VS launches the page I am working on. (what else would one want it to do????).
I mean, in some cases, sure, the page and testing of code must start from a known page. Then of course the user does things, sesson() vars etc. get set, and thus just "jumping" right into a page does not really allow you to correctly test your code or even launch that page out of sequence - so I well get this part and issue.
However, once logged in, (and the site remembers me), there is OFTEN a major page or part of some sub form that makes sense for me to startout on. And often a LOT of the pages I am working on "can" be launched without starting 5 web pages back.
So in "most" cases? I make some changes to code - whack the F5, and the code is compiled, and then VS launches the page I am on. This is without question what want to occur in 9 out of 10 times. And I often place in some respones.Redirects() in the page load event, since it NOT ONLY ME that has a problem by jumping to the wrong page. What if your users type in that URL too? They are free to do so!!! So, if YOUR development process is messed up by staring out on the page you are working on? Then 99% of the time, the your USERS ALSO can launch that web page and ALSO get messed up!
So, developing on a given page, hitting F5 to launch that page? It is a great default since you then over the development cycle get to catch funny errors when launching a page that you normally would not launch as your starting point.
And, as noted, often it might take 5 clicks and you traversing 5 pages to GET to the current page you are working on. If that page "can" be launched out of sequence, then you save buckets of pain during the development process.
So common is the above? Well, not only does hitting F5 just "start" your current page?
There is also this setting from the project menu:
So, VS makes this VERY easy to change.
But, the F5 behavior (current page you are developing on?) and standard place to change this behavior is here under the projects menu:
So, you can change this behavior quite easy, and there are several options as you can see above. You can even choose to not start a page.
So, the default is the current page you are working on, and in most cases this is what most developers prefer. However, as above shows, you have several options to change this.
i lunched an asp.net web-site. the main idea in the site is that:
the site shows the same page, but on each next button the user clicks, the pictures in the site change randomly. im working with postback and sessions.
i noticed that when a few users try to log into my site - their sessions are merging. meaning, the first picture presented is diffrent but the second picture is the same for all the users, and so on... (moreover, pictures that appears in the begining appearing again even thow i don't allw it in my code)
when i tried to debug the site locally, the random function works perfectly and there were no such problems. it haapens only when 2 users and more log into my site.
any suugestion how to solve it?
lots of thanks!
Is your randomizer declared as static?
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 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.
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.