This is the case:
Farm with one WFE and one APP-server. WFE hosts all sites, APP-server hosts all SharePoint web services. Names of servers: SPWFE01 and SPAPP01
WFE can connect to internet through proxy.
Web services should be bypassed, thus not called through proxy
Thus, I configured web.config as following:
<system.net>
<defaultProxy>
<proxy usesystemdefaults="false" proxyaddress="http://proxy" bypassonlocal="false" />
<bypasslist>
<add address="spwfe01"/>
<add address="spapp01"/>
<add address="139\.156\..*"/> <!-- IP-address range of Farm -->
<add address="10\.246\..*"/> <!-- backup IP-address range of Farm -->
</bypasslist>
</defaultProxy>
</system.net>
However, I get null reference exceptions when I call the UPA from code behind. When I remove above configuration, everything works as expected. Thus, web service calls are made through proxy, despite of bypasslist.
What am I doing wrong here?
Alright, fixed it by removing usesystemdefaults-attribute...
According to MSDN:
usesystemdefault
Specifies whether to use Internet Explorer proxy settings. If set to true, subsequent attributes will override Internet Explorer proxy settings. The default value is unspecified.
Thus, now it is "unspecified". I have no idea what unspecified is for a boolean value, but it works...
Related
We are hosting IIS ARR in a webapp running as a basic reverse proxy. This is working well and is really easy to configure (unlike the alternative we considered, Azure Application Gateway).
Our proxy takes an incoming url and simply forwards it to a different server so nothing too complicated.
What we need to do now though is to add a url rewrite rule for a tenanted endpoint, so with a url like this:
https://proxy/[customerid]/stuff?id=1
for customer A rewrite to
https://tenantservera/[customerid]/stuff?id=1
and for customer B rewrite to
https://tenantservera/[customerid]/stuff?id=1
Customers could be added at any time, and there are a number of these proxy servers deployed worldwide running behind Azure Traffic Manager, so I would prefer to avoid updating the web.config each time we add a new customer if at all possible.
This appears to be possible (though a bit archaic) with a "real" server running IIS as you can write a custom module in .NET 2.0, deploy to server's GAC and then hook it into the pipeline in IIS. This would update the web.config something like this:
<providers>
<provider name="DB" type="DbProvider, Microsoft.Web.Iis.Rewrite.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<settings>
<add key="StoredProcedure" value="GetRewrittenUrl" />
</settings>
</provider>
</providers>
Does anyone know if this, or anything like it, is possible in a web application? We can't install into the GAC AFAIK.
I have InProc SessionState enabled for my MVC appplication
<system.web>
...
<sessionState mode="InProc" cookieless="false" timeout="180" />
...
<system.web>
I have four independent VM's (Dev, Test, UAT & Prod) and unfortunately it does not work on one of them, e.g TempData is not passed between redirects.
I have checked...
IIS machine.config
IIS web.config
Applcation's web.config
Application pool settings
and they are all the same (alllowing for differences in connection strings etc)
Anything else I can check or any ideas as to what might be going on?
My dev and test environments are using the machine names whereas we have configured CNAMEs for the UAT environment as the end users are interacting with the server.
The problem was the hostname of the server... reporting_uat.xxx.com
As this contains an underscorre, IE will not store cookies, see Issue with Session and Cookie in Internet Explorer for websites containing underscore
I have been able to create a ASP MVC application that authenticates using Office 365 SSO.
I am looking for a way to have Office 365 as a SSO layer before accessing any internal applications (apache) we have on the network.
We have successfully setup a reverse proxy with ARR / URL Rewrite as discussed in this document:
https://confluence.atlassian.com/display/JIRAKB/Integrating+JIRA+with+IIS+using+ARR
The issue I am having is that URL-Rewrite is happening too high up the execution stack and bypassing any modules.
I am looking for some guidance on how to implement a Office 365 authentication layer on IIS for internal non ASP.NET applications that sits behind a firewall.
Any ideas?
I have experience with ARR and WIF. I had to become familiar with how IIS 7.5 handles native vs. managed code. I am assuming you are running your app pool in integrated mode otherwise the rest of this won't be applicable.
It's hard to know due to not knowing all the details on your issue but you could have a configuration issue related to managed vs. native/unmanaged code. ARR is a native http module. It is used in conjunction with the URLRewrite http module to allow content to be served up from a back end web server.
By default IIS does not run managed http modules for any requests processed by a native handler, such as ARR. To configure IIS to run a managed module for content processed by a native handler, such as WIF or other managed .NET code, you must configure IIS to run managed code regardless of the handler. The simplest way to do this is to set the runAllManagedModulesForAllRequests="true" in the system.webServer\modules element. You can also selectively enable individual modules to run by setting the precondition to "" to override the default IIS behavior:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="" />
<add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="" />
</modules>
Regards
I have a web application that is hosted by azure as a web role. The application is installed on two sub domains, QA and Production, the QA environment has the X-Frame-Options set to deny, but the production environment does not.
Currently the same code is deployed to each environment, so it must be a configuration option. I can't find anywhere in the web app where the XFO headers are set. Where else might the configuration be set?
I know this is old but still no answer so...
You can set it in the web.config like this:
<customHeaders>
<clear/>
<add name="X-Frame-Options" value="ALLOW-FROM youruri" />
</customHeaders>
I need help, I'm new to the WCF world having recently made the transition from SOAP Webservices.
The WCF service works well when I run in from the VS2008 ASP.NET Development Server i.e. Debug Mode. The problem comes when I try to access the service via IIS.
I've setup a website on my local IIS Webserver hosted on port 8082 (http://localhost:8082) and have created a VirtualDirectory (1.0) that points to the physical directory that contains my WCF Service code. The Website is setup to do ASP.NET 2.0.50727. I can get to the landing page and also an assortment of .aspx pages but when I try to access the Service.svc, the browser never gets there and just sits idling.
http://localhost:8082/1.0/Service.svc
My question is what setup am I missing to get the service to work from inside IIS since I already know it works under the development server.
I'm attaching part of my web.config if that would help.
<system.serviceModel>
<services>
<service name="Service1" behaviorConfiguration="Service1Behavior">
<!-- Service Endpoints -->
<endpoint address="" binding="wsHttpBinding" contract="IService1">
<!--
Upon deployment, the following identity element should be removed or replaced to reflect the
identity under which the deployed service runs. If removed, WCF will infer an appropriate identity
automatically.
-->
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="Service1Behavior">
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpGetEnabled="true"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
You talk about RESTful service, yet you're using the wsHttpBinding.... that's not the REST binding - that would be "webHttpBinding".
For the most part, WCF services ARE SOAP-based - any of the bindings except for the webHttpBinding are SOAP endpoints, so your wsHttpBinding endpoint is definitely not RESTful in any way, shape or form. You can communicate with it using e.g. SoapUI or better yet - the WcfTestClient in your Visual Studio folder.
You cannot however expect to get XML shaped data back from it by just browsing to that URL.
Marc
By default IIS 7.0 is not configured
for WCF services, we are going to
configure IIS 7.0 to run WCF services
i will break up the whole procedure in
steps.
http://basitblog.wordpress.com/2010/01/12/deploy-wcf-service-over-iis-7-0/