When i try to view a PARTICULAR page in my web site, it prompts for user name and password. Irrespective of providing proper user name/password and clicking OK or directly clicking Cancel button, the page is getting loaded properly. I am not sure why the authentication screen appears!!! It happens only for that particular page. Initially I thought it could be with file permission but copy pasted another page (which works fine) and renaming it doesn't solve the problem. Thoughts pl.
EDIT
I copied the source from the browser for that particular page and saved it as HTML. When i try to open the HTML file, it prompts for authentication.
Solution
I disabled the Integrated Windows Authentication in IIS and it works fine.
It's because some content is linked to a page that requires that (i.e. an image or a css file or a JavaScript file). Find out what it is, and make sure the link is correct.
Disabled the Integrated Windows Authentication in IIS and it works fine
Related
I deployed the web application in asp.net, there's one file named default.aspx that contains one script(ex : alert('dfdf');).
I removed the script and deployed again. The deployed default.aspx file doesn't contain the script. But after I copied the default.aspx file in Inetpub/wwwroot and access the page through web browser and checked view source : the script is present.
But, in Inetpub/wwwroot/default.aspx doesn't contain any script. I refreshed and restarted my IIS server and my machine too.
May I know why this happen to me? Help me guys
Yes you have the page on browser cache.
If you use google chrome, open the browser tools, then keep the click on the reload button for 3 seconds and a menu opens to gives you some option, like "hard reload" means that it will load the page with out cache.
Other way is when you change some page press Shift + click on reload button this is usually force to reload the page even if its on cache.
All the shortcuts for diferent browsers:
https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache
I've been tracking to tackle this issue and narrowed it down, but first a little description:
I have a website that a client would fill out, some basic text boxes, bullets, and dropdowns. They click submit and the information they submitted (nothing sensitive) is Response.Redirect(ed) to another page which has text boxes that are populated by the information included in the redirect. This page also prints itself for the client to sign.
The issue started when I added one more field to the redirect page so that it appears as well when printed. It simply does not appear on the page or the print out and I cross-checked the properties with all the other textboxes and everything is the same. Now, I did narrow it down in that the new textbox does appear when using the built in debugger for MS Visual Web Dev 2010 Express but it does not appear when I host the website on the local IIS server. From here it seems to be obvious that the issue is a setting on the IIS service.
To the question: What setting in IIS would cause a newly added textbox to not appear under the circumstances mentioned? Also, am I approaching this website as a whole in a round-a-bout way i.e. instead of redirecting to another website the populates data, prints itself, and redirects back to the host page is there an "internal" form I can have the data sent to and print from there?
The issue was that I setup the ISS server/website under and an administrator account with the website being under a folder on the desktop. I overlooked this fact and copy/pasted the website folder to the desktop of a different non-administrator account and so naturally none of the changes were actually showing because IIS wasn't even pointing to that website folder of the non-admin account. Once I dumped the modified files under the proper folder under the admin account they finally appeared in production.
I followed the instructions on how to add Recaptcha to my website (asp.net 4.0, Visual Studio / VB. When I run the page locally, which is just a simple contact form page that sends an email, the recaptcha thing shows up fine. I am NOT a programmer, though.
When I move it to production -- and I move the website (and the dll and pdb to the app_code folder and the bin folder, which Visual Studio created on its own), the page won't just refreshes and never sends an email -- and it doesn't matter if you type the right or wrong thing in the recaptcha textbox. Without the recaptcha code, the contact.aspx page functions normally and sends the email instantly.
But the recaptcha box is there. I've read things about handler mappings in IIS and my web.config, but I'm not intelligent enough to understand if I have to do anything or not, and what to do. I also have IIS 7.0 on here.
UPDATE:
When you enter the recaptcha information in the text box properly, the page displays the confirmation I encoded, and sends an email. When you do NOT enter the recaptcha info correctly, instead of sending a "Please try again" message, it just refreshes the page and makes them start all over again. It does not say "Please Try again" and doesn't leave the client with knowledge that they mistyped the code
Are you using the reCAPTCHA ASP.NET control with the Recaptcha.dll?
You need to have signed up for the service with a domain name. The public and private keys you receive are checked against this domain:
reCAPTCHA will only work on this domain and subdomains.
Notice it the admin page screenshot below:
But this rule does not apply on the localhost domain, which is what you use when developing with Visual Studio. So it may be that you are not using the keys that you received when registering your domain. When you select the control and switch from design view to code view in Visual Studio the control code should look like this, with the keys:
<recaptcha:RecaptchaControl ID="recaptcha" runat="server"
PublicKey="6Lexn8wSAAAAAIfH1c3-6K3FbSjcKdMj3uiMImI7"
PrivateKey="6Lexn8wSAAAAAKRFTJXTudJN1owrIQMDahwYv0hg" />
If not, you have to enter your keys. This is just an example, don't use these keys, use the keys displayed in your own account for your own domain.
I want to provide a means to open up Windows Explorer (or at least view the directory contents) via an internal webpage I've developed for our business. There are several machines which we share over the internal network. I've provided a text entry field for allow the user to enter the folder path they want to associate with a given row in a DB table and I can store that info off and create the file://///10.10.5.10/Recipes/Pie link to the Pie recipe folder on one of our shared machines.
The link renders correctly on the page and if I copy the link info and paste it into the address bar it will display a navigable page in FireFox or open Windows Explorer if using IE.
However, the link does nothing if you click on it directly on my page. I suspect this might have something to do with security and the brower, right? I've seen a SharePoint page in someone else's system that did work, but I'd guess that has to do with some differences between SharePoint and a webpage in a browser. The work-around of right-clicking the link and copy/pasting it into another tab will work and I might have to live with this, but I was wondering if anyone had any suggestions or ways to deal with this issue. Perhaps I'm just doing something wrong, but I'm pretty sure it's browser-security related.
It seems for me as a pure Internet Explorer setting issue.
First of all I would recommend you better use UNC or DNS names in the path to the server instead of the usage of IP addresses: use file://///myserver/Recipes/Pie or file://///myserver.mydomain.com/Recipes/Pie instead of file://///10.10.5.10/Recipes/Pie.
Second you should better include the file://///myserver, file://///myserver.mydomain.com or even file://///10.10.5.10/ to the "Local intranet" or at least to "Trusted sites" zone:
Then you should verify the setting of the Security Zone to which you map the url. Look at the "Miscellaneous" group for the "Display mixed contain":
If you would has "Prompt" setting you will see the warning:
at every attempt to open the link file://///myserver/Recipes/Pie
If you would has some problems I recommend you to reset the IE settings in "Advanced" tab:
Most likely it's a permission issue.
ASP.net runs under the ASP.net process account. Look for the ASPNET user and apply permissions to the folder for the user in question.
It definitely sounds like a security issue. Try one or both of the following:
Try using impersonation to impersonate a domain user with sufficient priveleges to access explorer on the client's machine
If this is a small intranet application, give the application full trust on the client
Here's a link to a class you can use for impersonation - see my answer:
Invoke or call C# console app from C# web service?
When using Visual Studio's built in web server, every time I make a page request the standard login box pops up and asks for credentials. It doesn't work if I actually put in my credentials, so I just have to hit cancel 5 times so it will go away.
When I run the application through IIS (locally or on test server) it works just fine (no login box comes up).
Anyone know how to fix this or have any idea what might be causing it?
I assume you mean JavaScript alert box-looking login dialog, right? This dialog pops up when you make a request to a portion of website where anonymous access is disabled from IIS. It is different from ASP.NET authentication.
Do you have some portion of web site protected? Or are you making any HTTP request to external sites, like images and etc?
If your page looks ok after hitting cancel multiple times, it must be one of those HTTP request to protected file like images, css, js or whatever.
I'd look in Fiddler or Firebug to see if any request is failed when you hit cancel in that login dialog.
I'd also try clearing cache/authenticated session on the page that runs on IIS to see if it actually shows you that login dialog.
I had this same issue. However, my solution was different and the issue seemed different as well.
I had been working on a ASP.NET 2.0 web application, using VS 2008. Everything was working fine with the built-in IIS server. I hadn't opened this project for about a week and then when I chose "View in browser" in VS, I was prompted for my windows login creds. This project never did this before, so I was a bit baffled. I checked all the web.config settings and everything seemed fine. My project settings seemed correct as well. I decided to test the project by opening this same project in VS on a separate dev box on my network using a network path. I again chose "View in browser" and it worked fine. No logon prompt.
This told me that the issue wasn't with the actual web project itself, rather my dev environment. I checked all my browser settings as suggested above, and they were correct. I then compared my project settings while I had the same project (same physical files) opened in both dev boxes. I noticed a difference...
Under the Start Option in the Property Pages, the Web Server was set to use the Default Web server in both cases. However, on the box that was asking for my creds, the NTLM Authentication checkbox was selected. I unselected this and it resolved the issue.
I'm not sure how this was possible since I was opening the same project files, and would assume the project settings would be exactly the same. And the fact it was working fine a week ago really perplexed me. I chalked it up to an issue with VS 2008 on the box with the issue. I hope this helps anyone else that may be running into this issue.
This was because localhost was not in my trusted sites so it wouldn't do automatic NTLM authentication... I'm not sure why it was that way, but it was... adding localhost to the list fixed it.
In your project, there should be a vwd.webinfo file.
The following lines control authentication when debugging (in IISExpress). Set as follows to avoid all dialogs.
<VisualWebDeveloper>
<iisExpressSettings anonymousAuthentication="enabled" windowsAuthentication="disabled" useClassicPipelineMode="false"/>
</VisualWebDeveloper>
If windowsAuthentication="enabled" you may still get a dialog, even if anonymousAuthentication="enabled" :-)