OK, this used to work, but it appears to have stopped working on January 1st.
We have a .NET page that is displaying some data to our internal mobile users. This page is set up with Anonymous Authentication in IIS7. (Windows Server 2008 R2 is the OS of the web server.) When accessing via our intranet, the page displays fine. When attempting to access via our Blackberries, we get the following error message:
"Error: Page cannot be displayed. Please contact your service provider for more details. (1)"
Is this an IIS error, an AT&T issue, or a Blackberry issue? My Director is on my case about it, and I'm not experienced enough in IIS to know of anything else that would cause this functionality...
You should check with your network ops team. I'm guessing that the blackberries are accessing the server from the external intranet (that's just a guess though) ... so have them double check that the domain/ip is accessible externally. That could be why you can access it from in the network.
Or if your blackberries are configured to access the network via VPN, I would double check that connectivity.
Forgot to post the resolution to this.
It turned out to be a Blackberry issue. With the latest OS, RIM combined the internal and external browsers into one browser. Said browser attempts to determine if a given site is an intranet or internet site. Even though the BES (sp?) was set up correctly, our service was still spotty. Some people could enter our intranet homepage address and get the intranet; others got the web squatter site on the internet. Since the page we were trying to access was nested fairly deeply in the directory structure, the web squatters didn't have a page with that name in their site. That's why we were getting the error shown above.
Our resolution - we created a different BES alias to point to our intranet, and rolled that out to all applicable users. Utilizing this, the browser didn't have to determine if we wanted our intranet site or the page on the internet; it correctly displayed the intranet page.
Related
My team is in the process of developing an Office 365 add-in, specifically to enable interaction with a hosted web application, and we're encountering a "Permission needed / Bad Request" error that we can't seem to pin down.
Context:
Developing and testing the add-in involves configuring an Azure Active Directory v2 application via the management portal as well as (for development purposes) creating an xml manifest file (which is for v1 apps as opposed to the json format for v2) that can be side-loaded via the O365 interface to provide access to our hosted app (currently only xml manifests can be side-loaded). We're still very much in the process of figuring things out in Office 365, as well as Azure/Active Directory and Microsoft Graph, and the documentation is fairly broad and doesn't always seem to be up to date.
Problem Description:
One of the problems that we're run into occasionally is encountering a "Bad Request" dialog message (in a browser dialog titled 'Permission needed') that is displayed when clicking the toolbar icon for our add-in. The actual URL being requested is similar to https://store.office.com/client/consentnotification.aspx with a number of parameters representing our application and it's required permissions. This results in an HTTP 400 with "Bad Request" being the only response content.
This is happening when the user clicks on our add-in in the O365 application toolbar and is occurring at the point where the user would have to authorize permission for the add-in.
This error seems to be related to the application configuration, but we can't seem to sort out how specifically (ie, some developers are encountering it, and others are not. Sometimes it'll show up if we recreate the Azure Active Directory application using one version of portal or another (there are currently two, with the v2 version being in preview).
Can anyone offer suggestions as to what might be causing this or provide information on why this might be occurring? We're not blocked, but it is rather annoying to deal with in development. I've done a fair bit of research trying to sort out why this is happening and I've gone through a number of tutorials/introductions on configuring Azure apps without success.
This turned out to be related to the Azure Active Directory Application configuration.
For the applications where this was occuring, the AADv2 application manifest was using a "signInAudience" value of "AzureADMyOrg". For cases where it was working as expected (ie, properly populating the permission request dialog) the "signInAudience" was set to "AzureADandPersonalMicrosoftAccount".
After some testing, the solution for our particular problem seemed to be either manually editting the AADv2 application manifest (json) to have "signInAudience": "AzureADandPersonalMicrosoftAccount", or via the Portal by setting the Application's Authentication Supported Account Types setting to be "Accounts in any organizational directory" (this results in a manifest setting of "signInAudience": "AzureADMultipleOrgs" which also seems to work).
Access to a web application for certain users (not all), at certain times (not always) results in the following error
In IE:
This page can’t be displayed Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in
Advanced settings and try connecting to https://SITEADDRESS again. If
this error persists, it is possible that this site uses an unsupported
protocol or cipher suite such as RC4 (link for the details), which is
not considered secure. Please contact your site administrator.
In Chrome, I get a ERR_CONNECTION_RESET
F12> Network tab shows no activity when trying to access the site.
Any ideas on what might be the issue and how to address it. The web application is built on Angularjs and is running on IIS
The issue in this case was the gateway that we were using for our VPN to Microsoft Azure. Upgraded that to Express Route and the issue went away
Recently I launched a WordPress site (Note: inmotion linux server) with Gravity Forms (GFrom). The site uses a GFrom as a job application and has an input for users to upload their resume. I have tested it, it works and I can login to the WP Dashboard View and Download all the entries ( in all browsers ) just fine.
After turning things over to the client, they came back to us saying they are unable to view or download the uploaded resumes from the Gravity Forms "Entries" section (Note: the client is able to access both the front and backend of the site, issue seems to only be related to the viewing and or downloading the resumes). They get a 404 error. Now the weird thing is, the 404 error they are getting was part of their old site on a completely different server (Note: Non WP on a godaddy windows server). They have tried clearing their browser cache and no success. Does anyone know what can cause this?
The Application
In short, the application surfaces data from a backend onto a web page. The client application is a Single Page Application made using AngularJS. It calls an ASP.NET Web API service located on a different domain to retrieve the data. I utilize BreezeJS on both the client application and the web service to manage this data. The client is hosted on a SharePoint Online site, and the service is hosted on IIS7.
The Error
I encounter an "Access is Denied" error when AngularJS attempts to make an XMLHttpRequest.open() call targeting this web service. However, though this seems like a simple CORS issue, it has some peculiarities which have me stumped:
Foremost, this error only occurs when using Internet Explorer 11 (or a previous version). When the application is viewed in Chrome or Firefox, it can connect and retrieve data from the service.
The web service is configured to accept the calling origin.
No network traffic is detected either by the native IE development tools or by Fiddler.
Specifically, the line: xhr.open(method, url, true); of the angular.js file throws this error.
Does anyone have any insight as to why this error occurs?
Also, if more specific details are needed I certainly can provide them. I'm not even sure where the issue might be coming from and I don't want to dump tons of irrelevant lines of code.
I think that this is due to using "localHost", i.e when attempting to access a resource in the "Local intranet" zone from an origin in the "Internet" zone.
See: Access denied in IE 10 and 11 when ajax target is localhost
This is not just a localhost issue as previously suggested. I have a production AngularJS application that is trying to POST to a public Web API 2 on a different domain. IE11, Chrome, and Firefox work without a hitch when the site is accessed externally. When accessing from a subnet that can talk directly to those servers, I get Access Denied and IE doesn't even send the request (Chrome and Firefox work flawlessly, of course. One workaround (I refuse to call this a fix) is to add the site as a Trusted Site in IE11. Even when the security settings for Internet mirror the settings for Trusted Site, I get access denied. I have to add the site on each internal IE system to gain access.
We currently have a Silverlight application which is hosted in a SharePoint 2010 page. The Silverlight app makes web service calls to a another server on our domain, which has a clientaccesspolicy file in place. We are experiencing cross-domain issues in our production environment.
Users in the farm admin group can use the Silverlight application without any issues. However, all other users recieve the generic cross domain exception when they try to use this app. We have attached Fiddler to the process and noticed that the farm admins are served the clientaccesspolicy file, but that non-admin users are not. In fact, Fiddler does not ever show an attempt to load this file for non-admins.
This only happens in our production environment, which leads me to believe there is a web config or permission setting causing the issue. Unfortunately, I cannot find anything that backs this up.
Has anyone else run into this issue or know if such a setting exists?
See comments above. I had to change the URL to use the full machine name i.e. from webserver/service.svc to webserver.domain.com/service.svc. It solved the problem but doesn't answer the question about why the farm admins could access it. vorrtex's response is the best possible explanation I have seen so far.