Deployed SL App giving NotFound from external machines

Deployed SL App giving NotFound from external machines

Old forum URL: forums.lhotka.net/forums/t/11411.aspx


bwebber posted on Wednesday, June 13, 2012

We have been trying to deploy our CSLA Silverlight app in our client's DMZ environment for 2 weeks now and cannot get over this final hurdle.

The SSL Certificate is installed and working.  The application uses an ASP login to authenticate the user before downloading the SL Application.  Everything works fine when running the site from the web server (IIS 7.5 btw).  We can login on the ASP login page, the SL app loads, the PrincipalGetter authenticates through the WcfPortal and the app runs perfectly.

However, when accessing the site from an external machine, the login is successful, the SL app downloads but the PrincipalGetter request returns the infamous NotFound exception. [HttpWebRequest_WebException_RemoteServer] Arguments: NotFound

I have downloaded the xap directly from the deployed site, extracted it and pasted the ClientConfig's endpoint address into my browser which correctly brings up the Service page.

Using Fiddler I have determined that the PrincipalGetter is definitely making its DataPortal call.

From here I am stumped.  I have read almost every post relating to this as well as the eBooks (multiple times) and the videos.  From what I can see all my configuration settings are correct.

We tried adding the cross domain policy xml files but this did not seem to fix the problem either.  From what I understand since the only WcfService we need to talk to is on the same server that hosts the Silverlight Application then these should not be necessary?

Here are the relevant configuration settings (note we used a CompressedHost called Singular.Compression.CompressedHost which inherits from Csla.Server.Hosts.Silverlight.WcfPortal):

Web.Config

   <system.serviceModel>

    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />

    <behaviors>

      <serviceBehaviors>

        <behavior name="serviceBehavior_IWcfPortal_SSL">

          <serviceMetadata httpsGetEnabled="true" />

          <serviceDebug includeExceptionDetailInFaults="true" />

        </behavior>

      </serviceBehaviors>

    </behaviors>

    <services>

      <service behaviorConfiguration="serviceBehavior_IWcfPortal_SSL" name="Singular.Compression.CompressedHost">

        <endpoint address="" binding="basicHttpBinding" bindingConfiguration="basicHttpBinding_IWcfPortal_SSL" contract="Csla.Server.Hosts.Silverlight.IWcfPortal">

          <identity>

            <dns value="localhost" />

          </identity>

        </endpoint>

        <endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />

      </service>

    </services>

    <bindings>

      <basicHttpBinding>

        <binding name="basicHttpBinding_IWcfPortal_SSL" maxBufferSize="10000000" maxReceivedMessageSize="10000000" receiveTimeout="00:40:00" sendTimeout="00:40:00" openTimeout="00:10:00" closeTimeout="00:10:00">

          <readerQuotas maxBytesPerRead="10000000" maxArrayLength="10000000" maxStringContentLength="10000000" />

          <security mode="Transport"></security>

        </binding>

      </basicHttpBinding>

    </bindings>

  </system.serviceModel>

 

ServiceReferences.ClientConfig

  <system.serviceModel>

    <bindings>

      <basicHttpBinding>

           <binding name="BasicHttpBinding_IWcfPortal_SSL"

                 maxBufferSize="10000000"

                 maxReceivedMessageSize="10000000"

                 receiveTimeout="00:40:00"

                 sendTimeout="00:40:00"

                 openTimeout="00:10:00"

                 closeTimeout="00:10:00">

          <security mode="Transport"/>

        </binding>

      </basicHttpBinding>

    </bindings>

    <client>

      <endpoint name="BasicHttpBinding_IWcfPortal"

          address="https://clientsite.com/WcfPortal.svc"

          binding="basicHttpBinding"

          bindingConfiguration="BasicHttpBinding_IWcfPortal_SSL"

          contract="WcfPortal.IWcfPortal"  />

    </client>

  </system.serviceModel>

 

ClientAccessPolicy.xml

<?xml version="1.0" encoding="utf-8"?>

<access-policy>

  <cross-domain-access>

      <allow-from http-request-headers="*">

        <domain uri="http://*" />

<domain uri="https://*" />

      </allow-from>

      <grant-to>

        <resource path="/" include-subpaths="true"/>

      </grant-to>

  </cross-domain-access>

</access-policy>

 

CrossDomain.xml

<?xml version="1.0"?>

<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>

<allow-http-request-headers-from domain="*" headers="*"/>

</cross-domain-policy>

 

Can anyone spot my mistake? Or give me any pointers on where else to look?

Thanks in advance ;)

bwebber replied on Wednesday, June 13, 2012

Another thing I thought about while on my way back from the client:

Due to the way the client has set up this machine, there is no Internet Access from the web server, we cannot view any external web pages from the web server at all.

All web sites running on the server still work with this limitation, but maybe this is what is stopping the Wcf communication?

RockfordLhotka replied on Wednesday, June 13, 2012

Since your server has a mex entry, you should be able to use discovery to get metadata about the endpoint. One thing you can try is opening Visual Studio, creating an empty client project, and adding a service reference to that endpoint. I suspect that won't work, but maybe Visual Studio will give you some more helpful diagnostic info about why it can't reach the endpoint.

bwebber replied on Friday, June 15, 2012

Hi Rocky

I tried adding a service reference for it and I get the following error:

"The document at the url https://clientsite.com/WcfPortal.svc was not recognized as a known document type.

The error message from each known type may help you fix the problem:

- Report from 'XML Schema' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.

- Report from 'https://clientsite.com/WcfPortal.svc' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.

- Report from 'DISCO Document' is 'Discovery document at the URL https://clientsite.com/WcfPortal.svc?disco could not be found.'.

  - The document format is not recognized.

- Report from 'WSDL Document' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.

Metadata contains a reference that cannot be resolved: 'https://clientsite.com/WcfPortal.svc'.

There was no endpoint listening at https://clientsite.com/WcfPortal.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

The remote server returned an error: (404) Not Found.

If the service is defined in the current solution, try building the solution and adding the service reference again."

If this rings bells for anyone please don't be shy to post ;)

We have used the exact same settings deployed to one of our own web servers using a self signed certificate and the SL app runs perfectly fine.

I am convinced this has something to do with the way the security has been set up at the client's site.  Somehow the Wcf communication is being blocked.

RockfordLhotka replied on Saturday, June 16, 2012

bwebber

I am convinced this has something to do with the way the security has been set up at the client's site.  Somehow the Wcf communication is being blocked.

That's what it sounds like to me too.

Have you tried using fiddler to watch exactly what goes back and forth over the network? That is probably your next step.

bwebber replied on Thursday, June 28, 2012

 

We finally got it working, I thought I would post how...

After working with our client's firewall guys they confirmed that the Wcf messages were being passed to the web server from the TMG server, but from the TMG server to the web server the communication no longer used SSL.

I tried a bunch of configuration options and finally got it working by configuring the client side Wcf config to use SSL and the web server Wcf config to not use SSL.

It no longer works when running it from the web server but is working fine when running it externally which is what counts!

This kinda makes sense to me considering the comms between the client and the TMG server is through SSL while the comms to the web server is not.  Maybe someone has some further explanations about this.

I'm just stoked it is finally working and I can get this monkey off my back ;) 

 

RockfordLhotka replied on Saturday, June 30, 2012

Thank you for sharing the solution.

I was having dinner with some people a couple nights ago while I was in SF, and one of them was an IT Pro networking guy. I mentioned your problem and solution, and how I'd never heard of such a thing. He said it is not real common, but isn't uncommon either. Apparently the reason for doing this is twofold:

  1. Offload the SSL encryption work from the web server
  2. Allow the firewall to examine data after it has been decrypted, but before it flows to the web server

So I appreciate you sharing the solution, because I certainly learned something interesting.

Copyright (c) Marimer LLC