A cheeseburger to the first person who can help me make sense of this. I have a page in a Sharepoint app that uses Telerik's RadUpload to upload files. This has worked for months; last week it stopped working (in Internet Explorer, this detail is important). After talking with a co-worker about the problem, I tried the upload with Firefox; it worked. Not only that, all subsequent uploads from Internet Explorer started working. Flash forward an hour, and the aforementioned coworker, on another Sharepoint site, running on different servers, was having problems downloading (using Internet Explorer). Being half serious, half smart-aleck, I said 'try it in Firefox'. Not only did that work, ALL SUBSEQUENT DOWNLOADS IN INTERNET EXPLORER WORKED! And he re-produced this behavior on another machine. My fear is that this a browser issue. All advice will be greatly appreciated.
a
IE will try and present credentials to a server it knows to be in its Local Intranet zone when it tries to connect (depending on the setting of "Automatic logon only in Intranet zone").
Firefox will only present credentials when prompted, and will generally ask you by popping up a box (unless you've configured a list of sites for it to always present NTLM credentials to).
I've seen a similar case with Sharepoint where you can cause IE to work by logging in with Firefox. I theorized it was due to a permission on a remote resource being for "Authenticated Users", and you're causing your user to authenticate by logging in forcefully. We eventually set the "Automatic logon only in Intranet zone" to "Prompt" and it worked. My theory there was that it wasn't detecting the site as being in the Local Intranet zone for some reason. If you're not accessing a domain with no .'s in it, try also setting your Local Intranet site policy to match the full domain of the Sharepoint server, not just *.example.com - I've read that that can help.
Was it as simple as IE not re-downloading miss-cached .js file, maybe, that firefox did download, making IE work after that?
Pretty gnarly to debug.
Related
My website is working with some ISP while it is not working with others. Also not working from other countries.
The app is hosted at our company. Developed using sharepoint asp.net.
The app works at my home.
But if I visit the website at my brother's home who is registered to different ISP, the website opens and a login dialog appears. When entering correct username and password then submit , textboxs cleared and dialog come again.
The problem is happening with many visitors.
I just want to know what would be the problem! Does anyone faced such problem before?
I checked all IIS restrictions. There is no restrictions made.
I created a new app using sharepoint with login page and it works great.
somebody said that users with public ip can access the site while others with dhcp cannot. Can somebody explain that !
Some ISPs have transparent proxies in use. And some of them are accidentally (or even intentionally) broken and cache more, than they should. You can check whether that's the problem:
Set up your server to also allow https and then use that. You should move to https for privacy reasons anyways, so just do it now ;)
This way, the proxy can't do anything but to pass the data between client and server unmodified.
If that is not an option: Use tcpdump/wireshark/other-sniffer on both - client and server - at the same time and compare the logs. Did the second access even make it to the server?
Do you have a laptop/tablet/smartphone with which you can access the web server? Try moving that laptop from one location to the other and check, whether it works with that one laptop using one ISP and fails with the same laptop on the other ISP.
This should be a comment, but I do not have enough to post it as such.
Are sure that it is not a browser issue?
Is the login dialog from SharePoint, your app or the browser itself?
If it is from your app, can you debug it or write the log-in attempts in a log?
Good morning all!
I am a sysadmin with a medium-sized business. I'm in workstation support, not part of the web team or server support. I have a single user who gets an information bar at the bottom of IE every time he opens our own company's homepage:
Internet Explorer blocked this website from displaying content with security certificate errors.
I am pretty sure this is a workstation issue, and not serverside. I cannot replicate the problem on any of our other machines. The browser still navigates out to the site, it doesn't show the "There is a problem with this website's security certificate" page and try to block access.
I have opened the certificate by clicking on the padlock icon in IE and I can't see any warnings about the certificate. Did the same in Chrome and can't find any issues.
I did a Clear SSL State in IE on the user's machine, and the issue still isn't resolved. Other HTTPS sites work appropriately.
As this is our own URL, it is a trusted site in IE by group policy. I have checked that the same is true on the user's machine.
At this point I am not 100% sure that there isn't actually an issue I need to report to the web team. Nothing I have tried seems to be able to clear this single machine of the notion that something is wrong with that certificate but I can't confirm it either way.
The website's URL is https://www.ruffalonl.com/
Assuming nothing is wrong with the site or the certificate, does anyone know a way of suppressing the blasted message in IE? Either I make this message go away, or I am going to get a support ticket from this user that says something is wrong with the website every single day until I die.
I have a Java web application in domain A (that we control). This application displays another website located in domain B (which we do not control) in an iframe. This external website was recently updated to require users to log on before they can see content. They provided us with a URL that will automatically log our users into their site. This URL works when we navigate directly to it in Internet Explorer (we get automatically logged in etc).
However, apparently there was an update to Internet Explorer so that cross domain communication is not allowed. So now when the login URL is displayed in the iframe, it does not successfully log on (I am guessing its being blocked from creating security cookies).
Also, if we browse to the URL directly and get the security in place, then any iframe elements of the site will not work (I am guessing it is being blocked from accessing security cookies).
Does anyone know of a work around for this? Changing the security level on Internet Explorer is not an option (it is controlled by our company's system administrator). Internet Explorer is also our company standard, so we cannot change that (even though it works fine in Firefox).
When you say "elements of the site will not work" what precisely does that mean?
"Cross-domain" interactions have always been restricted in all browsers. This is called "same-origin-policy" and it's the foundation of web security. The "update" to Internet Explorer you're referring to restricts IE such that a webpage on Domain A can no longer navigate a subframe that is inside a page from Domain B. That restriction has been present in IE for 7+ years and is in all browsers. This restriction is not causing your problem.
This most likely problem here is that the subframe fails to set a P3P header that would permit its cookies to be stored. There are perhaps 30 duplicates on that issue on StackOverflow.
To determine if this is what you're encountering, try this:
In IE, click Tools > Internet Options > Privacy tab.
Set the slider to Accept all
Clear your cookies
Restart the browser and retry the scenario.
If this change solves the problem, then the fix is easy: configure the page which is being framed to specify its cookie policy using a P3P response header.
If this doesn't solve the problem, please update the question with more information that would allow others to reproduce it (e.g. traffic logs, live site URL, etc).
It turns out that this was causes by the login site not being on the trusted sites list. Having security add it as a trusted site and pushing that to all company computers solved the issue.
my website opens with xx.xxx.xxx.xxx IP address till friday it was working fine..after wards not able view the site in webbrowser...what could be the problem ? how can we solve it?
My server with this IP is working and can able to view the updated data in database ..but not able to view, or open the page of website.before the website under IIS configuration was stooped and now started again..still no use..am couldnt view Login page at all.My application was developed in classic asp long back.Kindly give me any suggestion to this...its very urgent...
I tried browsing the website in IIS manger(server) .It showing page cannot be displayed.
Thanks in advance.
First, Don't Panic. Staying calm can avoid further damage.
While it's hard to tell what could be the problem, the first thing you can do is to "ping" the domain from terminal.Can you login remotely? "wget" (on linux) will download the files from website, and could help you see if the files on the site are still accessible. Check from different browsers or machines, if possible. I'm no expert in asp or IIS, so won't advice on that front. But once I had faced the same situation with my website. So I just called up the hosting service provider, and it turned out it was their problem, and they brought the server online. If it's okay from their end, you might have changed some configurations in your server or application or there might be some up-gradation changing parameters, or even an accidental deletion/ moving/ renaming of files. Just try to remember what are the things you did with your server and application, before it went down, and also ask your server administrator. That will surely help you understand the problem better, if not help to solve it right away.
Good Luck.
hi
i have a problem at my production site, client reported that he is not seeing data in lists of sharepoint, as well drop downs which have years in pages of site appear empty with one user A on machin X having with windows 7. but data and comes up and drop downs are now populated when accessed from machine Y with same user A.
i dont knw wht really the problem is. As to development site this issue is not produced,
plz help,
thnks in advance
From your question, I gather the data does exist and the same user can see the information from one computer but not another.
A couple things spring to mind. (I am presuming usage of Internet Explorer since SharePoint 2007 has some rather weird rendering issues with other browsers. Correct me if this is an incorrect assumption.)
First, Windows 7 has later versions of IE which can refuse to send network credentials to a server it doesn't think is part of the intranet (corporate network). What makes this especially frustrating is that IE will prompt for network credentials (a result of the challenge from the website) but will not transmit those credentials. Examine the IIS logs to see if this is the case. The requests will be void of credentials using IE but will be present using Firefox (and presumably any other web browser). The fix for this is usually as simple as adding the domain into the Local Intranet zone in Internet Options.
If this is not the case, can you confirm the user is using the same credentials? Is this integrated authentication using Active Directory or forms authentication?
Are there any differences between the two computers with regards to how they reach the SharePoint site? (Such as one is VPN, the other is directly connected)? Or are they essentially equal but with different browser/OS configurations?
Are the lists standard out-of-the-box lists or have they been customized with SharePoint Designer or any other means? Are you injecting JavaScript via a Content Editor Web Part which might not be executing correctly?
It would be very helpful to know browser versions used, OS versions used, differences in connectivity to the resource from each machine, type of authentication used, and any other thing you can think to list.
I wish you luck in tracking this down!
Windows 7 or xp has nothing to do over here probably it has to do with the browser which he is using to browse the site ask him to chk the internet explorer settings and verify that he has enabled execution of javascript and other related things