I'm having issues with configuring the Dataportal on an internet facing box. I have set the dataportal up in one directory and set the NTFS permissions to Read/Execute for the anonymous user. I point two virtual directories to this file location, one on the default web site and another on a named subdomain on the internet. I checked that the security permissions are identical between the two sites in IIS.
I can access it fine when working with the Intranet zone (localhost) when testing against http://localhost/DataPortal/RemotingPortal.rem?wsdl in that I get the standard remoting reponse. If I change this to the intranet zone at http://MyServer/DataPortal/RemotingPortal.rem?wsdl, I get a 403.1 execute permission denied, which I think is tied to the CSLA based custom principal. I can test accessing this version of the remoting channel by doing a Principal.Login and that succeeds, thus it appears the remoting channel is working correctly in the Intranet zone. If I try to move this out to the extranet zone with http://MyServer.MyDomain.com/DataPortal/RemotingPortal.rem?wsdl, I get a http 500 error response, "Server encountered an internal error. To get more info turn on customErrors in the server's config file.". Changing the customErrors flag does not provide any additional information. If I try my test rig, I get a "SerializationException: The input stream is not a valid binary format" because the server is returning the http 500 error text: "Server encountered an internal error. To get more info turn on customErrors in the server's config file." rather than the binary stream.
I'm suspecting there is a problem with the internet zone with the Reflection portions of the dataportal and this is causing the server error. I have tried adding CSLA.dll to the trusted code group on the server, but that has not solved the problem. I have not yet tried adding it to the GAC. I was hoping someone else could assist with suggestions before I go too far down that route. Any and all suggestions are helpful.
Jim
Hi,
One thing that recently caught me out with IIS was .net 1.1 and .net 2.0. Check that IIS is set to use .net 2.0 if using CSLA 2.
Just a quick suggestion as its something that cought me out.
Regards
Craig
Yes, both sites and virtual directories are configured for the 2.0 framework.
On a side note, I have confirmed that the url is correct for my external version by placing a "helloworld.htm" file in that directory and navigating to it correctly.
Jim
Update:
I have tested the remoting with PTracker and am experiencing similar behaviors.
Testing //localhost/PTRemoting/RemotingPortal.rem?wsdl works locally.
Testing //MyServer/PTRemoting/RemotingPortal.rem?wsdl works locally.
Testing //MyServer/PTRemoting/RemotingPortal.rem?wsdl fails remotely when accessing from XP sp2 to Win2k3.
If I host this on the XP box, I am able to remote into the XP box from the 2k3 box with no problems.
This leads me to suspect an issue with rights on the 2k3 box. I am using anonymous Authentication. I set IIS for allow scripts and executables. I set NTFS to allow both the aspnet user and IUSR_Server (anonymous user) to have read and execute rights on the folders/files. I have even adjusted CASPOL to set CLSA and ProjectTracker.dll to full trust on the server.
Accessing HelloWorld.aspx works fine, so there doesn't seem to be an error in the config file. The only thing I changed in there was the ConnectionStrings anyway. Any sugestions are welcome.
Jim
Jim, this may be a long shot, but I've seen a case a while back on a 2k3 server where a coworker of mine had to add read/write ritghts to IUSR_<machinename> to the "Windows\Temp" folder. It could've been IWAM instead of IUSR. It's been while so I'm not sure.
Also, make sure your dlls are properly signed.
Again, not sure if this will help at all with your situation but it won't hurt to give it a try.
Copyright (c) Marimer LLC