IE Hosted UserControls blocked by 3rd Party Tools?

  • Thread starter Thread starter Wells Caughey
  • Start date Start date
W

Wells Caughey

Hi everyone,

I have a strange and difficult to debug situation: I have developed and
deployed an IE hosted Windows Forms UserControl as part of my company's web
portal, and for just about all of our clients everything has worked well.
But for one client who is running XP SP2 and has the .NET framework
installed, the DLL is downloaded (he can see it in
c:\windows\assembly\download) but never runs on the web page. Does anyone
know of any 3rd party products/tools such as Spybot Search & Destroy that
may hamper or cause the UserControl not to run? Are there any specific
system settings that I can check that might cause this problem?

Thanks
Wells
 
Thanks for the advice but I don't think that the .NET security settings are
the problem. I have people both inside and outside my company on XP SP2 who
are able to load the webcontrol without a problem. Just to make sure, I
even had my site added to the "Trusted Zone" on the computer that is giving
us problems, but to no avail.

Wells
 
Hello Wells,
It seems that SP2 has locked down on some security that didn't exist prior. You could use caspol on the machine that doesn't work or .NET Config 1.1 wizard to try different security settings to verify if all security permissions are set correctly.


Best of luck!

Your C# ally ,
RBischoff


WC> Hi everyone,
WC>
WC> I have a strange and difficult to debug situation: I have developed
WC> and deployed an IE hosted Windows Forms UserControl as part of my
WC> company's web portal, and for just about all of our clients
WC> everything has worked well. But for one client who is running XP
WC> SP2 and has the .NET framework installed, the DLL is downloaded (he
WC> can see it in c:\windows\assembly\download) but never runs on the
WC> web page. Does anyone know of any 3rd party products/tools such as
WC> Spybot Search & Destroy that may hamper or cause the UserControl
WC> not to run? Are there any specific system settings that I can
WC> check that might cause this problem?
WC>
WC> Thanks
WC> Wells
 
Hi Wells,

Just a bit suggestion to verify whether the problem concerned with CAS. We
can use the CASPOL.EXE to turn off the CAS checking on that client machine
to see whether the UserControl can work well. Just use the
caspol -s off in the command line:

#Code Access Security Policy Tool (Caspol.exe)
http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfCodeAccessSecurity
PolicyUtilityCaspolexe.asp?frame=true

In addition, since such IE host issue is difficult to troubleshooting, the
following kb has discussed on using the IE host log on clientside to trace
the error, maybe can provide some clues.

#HOW TO: Use the IEHost Log to Debug .NET Object Hosting in Internet
Explorer
http://support.microsoft.com/default.aspx?scid=kb;en-us;313892

Hope helps. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Thanks Steven.

Because this is a client's machine and not one of our machines, I didn't
want to make any major changes. However if the problem continues, I will
explore this path if, for no other reason, to reaffirm that it is not a
security issue.

Thanks,
Wells
 
Thanks for your response, Wells,

Well, if you meet any sequential problems, please feel free to post here.
Thanks.

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Well, I finally got the chance to try the caspol trick. We actually went to
the client's office and picked up his computer and brought it to our office
so we could examine it. As it turns out caspol -s off made absolutely no
impact. I did figure out that the reason the UserControl failed was because
it was unable to complete a webservice call that intializes it. The error
it returned is that the web service timed out, which I find extremely odd
because the webservice essentially returns a constant; it makes no database,
filesystem, or network calls that could block.

The machine had a good number of spyware removers, virus scanners, and the
like, but I was never able to isolate the source of the problem. In a last
ditch effort we created a new user account and tested the UserControl from
there, and surprisingly it worked!

Does anyone know of any specific products that might have somehow disabled
webservice calls?

Thanks,
Wells
 
Hi Wells,

Oh, thanks for your details feedback!

In server side, is your webservice hosted in IIS? If so, which
authentication mode your webservice used, does it allow anonymous
authentication?

Also, it seems after creating a new user account at client machine, the
problem has been resolved, do you stil have any concern on this issue?

thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Hi Jeffrey,

Yes, our webservice is hosted in IIS and at the IIS level it uses anonyomous
authentication. More specifically, when a user browses our website I use
the FormsAuthentication_OnAuthenticate to unwrap/decrypt a cookie I set when
the user logs in. When the user browses to the page containing the
UserControl, I use the window.onload event to copy the cookies out of the
browser and into the UserControl. UserControl adds the cookies to the
WebService's CookieCollection and makes calls back to the webservice at that
point. The webservice is part of the same web application as the web site.

I do not believe that the way I flow the authentication from the browser to
the UserControl is the source of the problem; So far it has worked without a
hitch for 95% of the machines we have tested it on.

I suppose that creating a new account is a solution, but it isn't a great
solution, and whats more it doesn't help me know how to solve similar
problems in the future. If you know of any 3rd party software this
individual may have installed on his machine that would prevent me from
making webservice calls, I'd love to know what they are.

Thanks,
Wells
 
Hi Wells,

Thanks for your details explanation!

Based on your description, I think the difference between the old account
and new account should only be the setting on the system, so there may be
some different setting on cookie that is sent.

I suggest you use script to print out the cookie that is copied to
usercontrol under these 2 different account, then we can see if there is
any difference between the cookie that the machine sent under old and new
account.

I will wait for your further feedback and more information. Thanks

Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Jeffrey,

That's a good thought about making sure the cookie gets setup correctly
under both accounts. While I did not test whether the cookie got setup
correctly under the new account (the account that works, so I assume the
cookie is correct) I did use script to popup a dialog box with the value of
the cookie in the old account, and everything appeared as I would have
expected. The cookie is an encrypted string so I could not verify whether
the value of the cookie was correct, but if it had not been correct my
Global.asax would have redirected the request to the login page and I would
have gotten an "object moved" exception from the webservice. I have seen
this exact senario previously, while the program was still in development,
and the two exceptions are distinct.

The only thing I can thing I can think to do now is to somehow attach a
debugger to the web server and try to see what is going on. This will be
particularly difficult because I already have many different users using the
system.

Thanks,
Wells
 
Hi Wells,

Sounds really strange. Before you try attaching debugger onto the server
process, I think there is still something we can trace at clientside. I'm
not sure whether you've ever installed the MS SOAP toolkit3 which contains
a Trace Utility tool that can help capture the raw SOAP MESSAGE (HTTP
HEADERS) sending out and response back. Then, we can compare the soap
messages sending under the two different accounts to see whether there is
any certain difference.

You can get the soap toolkit3 here:

http://msdn.microsoft.com/webservices/building/soaptk/

Hope helps. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Steven,

I had to give the client his computer back, so there isn't really anything I
can do right now. It is however possible that I might get another chance at
his computer at some point in the future, and if so, I will try caputring
the SOAP Message as you described. Just one question though: when I
followed the URL you supplied, the site said that the Soap toolkit had been
depricated by the .NET framework. Will this trace utility allow me to trace
the soap calls even though I am not using COM or the Toolkit to make my
WebService calls? I currently use C# and the .NET framework to make those
WebService calls.

Thanks,
Wells
 
Hi Wells,

Thanks for your followup. Yes, the SOAP TOOLKIT is depricated , this is
because the SOAP TOOLKIT used to be the tools for generating webservice's
WSDL or client proxy and now the .net framework has much more stronger
functions on this. But the Trace Utility is a small tool contained in the
soap toolkit which is only used for testing. It just listen on a certain
port and then capture all the SOAP messages on that port and forward the
message to the destination port (address) we speicfied. In othe word, it
dosn't concern with whether we're using soap toolkit or .net framework to
build the webservice. Just a trace tool such as net monitor.

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Back
Top