|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Re: IE Hosted UserControls blocked by 3rd Party Tools?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 ""Jeffrey Tan[MSFT]"" <v-je***@online.microsoft.com> wrote in message Show quote news:mMgwYuF0EHA.1884@cpmsftngxa10.phx.gbl... > 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. > 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 Show quote "Steven Cheng[MSFT]" <v-sch***@online.microsoft.com> wrote in message news:Ee4Cdif0EHA.3984@cpmsftngxa10.phx.gbl... > 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.) > 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.) |
|||||||||||||||||||||||