Getting rid of Sharepoint Site HTTP 403 Error - Forbidden or Access Denied error - Part 2(Continued)

When Client Script make a call to ajaxenabled webservice, the javascript proxy file containing proxy to access the web service is generated on the fly. you can view release version of it by appending /js after the webservice url and for debug version type /jsdebug.

Example of javaScript Proxy for Web Service

To generate such a proxy on the fly read& execute permission is required for the user to the toolkit assembly. So either proxy should be created with admin privileges or all users must have Read&Execute permissions for this file.
Otherwise, non-admin users will get 403 error.

Another solution is that you can create this proxy manually, include it as script reference and on the fly generation of proxy is no more necessary.
But, you need to be very careful with this approach if you are changing the webservice very often. In that case, you need to generate the proxy file everytime you add/remove/update webmethod and include it manually.

You can also modify ur code to make sure that you always use elevated privileges to generate this proxy.

Apart from all these, also ensure that web.config should have following entry with validate = 'false':

<add name="ScriptHandlerFactory" verb="*" validate="false" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

if validate='false' is not included, potentially HTTP 403 may be thrown while accessing dynamically generated proxy.


After making all these changes, our intermittent HTTP 403 error problem was not solved yet.
So, let us continue our investigation!!!!

3. By now, IIS log was displaying very generic error, something like this:

2008-06-11 10:43:59 W3SVC1396598049 170.116.208.211 GET /sites/TKR2/tkr2+pages/tkr2main.aspx - 10011 AMER\SKALERISD 10.128.129.32 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322;+InfoPath.1;+.NET+CLR+2.0.50727) 403 0 0


Log entry shows that HTTP 403 is shown for page but doesnt show for which resource on the page.
So, I started analyzing Event logs. I didnt find any error entry there related to this but found an information entry, something like this:

Event code: 4011
Event message: An unhandled access exception has occurred.
Event time: 6/11/2008 6:43:59 AM
Event time (UTC): 6/11/2008 10:43:59 AM
Event ID: a6d7b8c987494a64a763f11ae0bcadac
Event sequence: 111
Event occurrence: 11
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1396598049/Root-1-128576392451406250
Trust level: Full
Application Virtual Path: /
Application Path: C:\Inetpub\wwwroot\wss\VirtualDirectories\10011\
Machine name: AMRNDHW034

Process information:
Process ID: 8116
Process name: w3wp.exe
Account name: AMER\srvmop-ecfstg

Request information:
Request URL: http://amrndhw034:10011/sites/TKR2/tkr2 pages/tkr2main.aspx
Request path: /sites/TKR2/tkr2 pages/tkr2main.aspx
User host address: 10.128.129.32
User: AMER\SKALERISD
Is authenticated: True
Authentication Type: NTLM
Thread account name: AMER\srvmop-ecfstg

Custom event details:

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.


If you observe carefully, the time is same in both entry. So, if you try to read this information, the .net runtime is throwing an exception which is unhandled and that's why the execution thread was being aborted.

Now, the question is why the runtime ws throwing an exception.The Event message says that unhandled Access exception has occured. So, still some resource is still violating the access protocol, but who?

I then started working with debug build of AJAX Control Toolkit and found that some line in toolkit code was throwing access violation error which was unhandled and it was really causing asp.net runtime to abort the thread.


The toolkit was throwing the error as i was using toolkit as private assembly and it was located in bin directory of the web application. This assembly was being loaded with the user's identity contrary to other dlls in bin directory where they were loaded with IIS process account.

So, the solution is that:
1. Grant Read & Execute permission to every user for this assembly
or
2. Place the assembly in a directory where already all users has access to it
or
3. Place it in GAC

and finally, our problem got solved.