Thursday, June 12, 2008
Getting rid of Sharepoint Site HTTP 403 Error - Forbidden or Access Denied error - Part 3
Some other considerations:
Here I am assuming that the sharepoint is installed at standard location "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12".
ISAPI-where the web services should be placed
TEMPLATES\CONTROLTEMPLATES - where usercontrols are placed
wpresources(under ur webapplication directory)- where webpart resources are placed.
all these directories have "ServerName\Users" group added with "Read","Read&Execute" and "List folders" permissions. this group contains IIS guest account, IIS process account and ASPNET account and othe users for server. So by default, all authenticated users can access the resources under these directory but the Bin directory under your Web application doesnt have this group added so be careful if u are adding any resource that requires all users to have Read or Read&Execute permissions.
Here I am assuming that the sharepoint is installed at standard location "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12".
ISAPI-where the web services should be placed
TEMPLATES\CONTROLTEMPLATES - where usercontrols are placed
wpresources(under ur webapplication directory)- where webpart resources are placed.
all these directories have "ServerName\Users" group added with "Read","Read&Execute" and "List folders" permissions. this group contains IIS guest account, IIS process account and ASPNET account and othe users for server. So by default, all authenticated users can access the resources under these directory but the Bin directory under your Web application doesnt have this group added so be careful if u are adding any resource that requires all users to have Read or Read&Execute permissions.
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':
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.
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.
Getting rid of Sharepoint Site HTTP 403 Error - Forbidden or Access Denied error
Recently in our sharepoint web application i encountered HTTP 403 error for one of our web page. The strange thing about this error was that nature of the error was intermittent. i.e. sometimes user was able to view the page but sometimes users were receiving 403 response from web server.
The problem was further complicated by the fact that users were able to access the page once any admin users log in and access the page. after sometime, they were used to complain about 403 error.
If i reset the IIS or restart the server, once again all users were started receiving 403 error again. So something was terribly wrong!!!
We had Ajax enabled custom sharepoint smart part(webpart with user control) on the page and when i have removed the part from page everything was working fine. But, that's not the solution. But, one thing i could conclude that something is wrong with the webpart. But what, let us investigate!!!
(Webpart debugging in sharepoint becomes complex when Ajax and user controls are part of it.)
In my case the response was following:
but it can be in nay of following form:
1.
You are not authorized to view this page
You do not have permission to view this directory or page using the credentials that you supplied.
--------------------------------------------------------------------------------
2.
Please try the following:
Contact the Web site administrator if you believe you should be able to view this directory or page.
Click the Refresh button to try again with different credentials.
HTTP Error 403 - Forbidden: Access is denied.
Internet Information Services (IIS)
--------------------------------------------------------------------------------
3.
Technical Information (for support personnel)
Go to Microsoft Product Support Services and perform a title search for the words HTTP and 403.
Open IIS Help, which is accessible in IIS Manager (inetmgr), and search for topics titled About Security, Authentication, and About Custom Error Messages.
Solution:
As the error message clearly indicates that you are not authorized to access some resource. It could be page itself, image, css, xml files, web service files(.asmx files), assembly(yes, assembly!!!) , resource Assembly(satellite assembly) or any other resource you can think of.
I started debugging with HTTP error logs and IIS logs in order to identify the resource forwhich HTTP 403 was thrown.
1. First i found that the users are getting 403 errors for some XML files that we were consuming in our webpart. As we didnt assign Read permission and users's identity is used to access the resource by default,access was denied to non-admin user.
in this case, we have two solutions:
1. Grant "Read" permissions for every authenticated user.
2. Use elevated permissions(SPElevatedPermission)in code while accessing the files.
I opted second solution.
2. Then after we found that, 403 is being thrown on webservice.asmx/js file. We were using lot of ajax in webpart. this particular webpart was contacting autocompleteservice.asmx to get the suggestions for autocomplete textbox. When asp.net ajax make call to webservice through client, it creates javascript proxy on the file. You can view this java script proxy by appending /js afte webservice url.
(For instance, if your webservice is available at http://somehost/webservice.asmx, you can view it's java script proxy by typing http://somehost/webservice.asmx/js in ur browser address bar.But make sure that your webservice are marked with [ScriptService] in your code otherwise the java script proxy won't be generated.)
More Coming in next post soon....
The problem was further complicated by the fact that users were able to access the page once any admin users log in and access the page. after sometime, they were used to complain about 403 error.
If i reset the IIS or restart the server, once again all users were started receiving 403 error again. So something was terribly wrong!!!
We had Ajax enabled custom sharepoint smart part(webpart with user control) on the page and when i have removed the part from page everything was working fine. But, that's not the solution. But, one thing i could conclude that something is wrong with the webpart. But what, let us investigate!!!
(Webpart debugging in sharepoint becomes complex when Ajax and user controls are part of it.)
In my case the response was following:
but it can be in nay of following form:
1.
You are not authorized to view this page
You do not have permission to view this directory or page using the credentials that you supplied.
--------------------------------------------------------------------------------
2.
Please try the following:
Contact the Web site administrator if you believe you should be able to view this directory or page.
Click the Refresh button to try again with different credentials.
HTTP Error 403 - Forbidden: Access is denied.
Internet Information Services (IIS)
--------------------------------------------------------------------------------
3.
Technical Information (for support personnel)
Go to Microsoft Product Support Services and perform a title search for the words HTTP and 403.
Open IIS Help, which is accessible in IIS Manager (inetmgr), and search for topics titled About Security, Authentication, and About Custom Error Messages.
Solution:
As the error message clearly indicates that you are not authorized to access some resource. It could be page itself, image, css, xml files, web service files(.asmx files), assembly(yes, assembly!!!) , resource Assembly(satellite assembly) or any other resource you can think of.
I started debugging with HTTP error logs and IIS logs in order to identify the resource forwhich HTTP 403 was thrown.
1. First i found that the users are getting 403 errors for some XML files that we were consuming in our webpart. As we didnt assign Read permission and users's identity is used to access the resource by default,access was denied to non-admin user.
in this case, we have two solutions:
1. Grant "Read" permissions for every authenticated user.
2. Use elevated permissions(SPElevatedPermission)in code while accessing the files.
I opted second solution.
2. Then after we found that, 403 is being thrown on webservice.asmx/js file. We were using lot of ajax in webpart. this particular webpart was contacting autocompleteservice.asmx to get the suggestions for autocomplete textbox. When asp.net ajax make call to webservice through client, it creates javascript proxy on the file. You can view this java script proxy by appending /js afte webservice url.
(For instance, if your webservice is available at http://somehost/webservice.asmx, you can view it's java script proxy by typing http://somehost/webservice.asmx/js in ur browser address bar.But make sure that your webservice are marked with [ScriptService] in your code otherwise the java script proxy won't be generated.)
More Coming in next post soon....
Subscribe to:
Posts (Atom)
