HTTP:403 CheckUserAccess.aspx

Aug 20, 2009 at 5:56 AM

 

Just wandering if you had any thoughts I my issue.

We have a split install - WebFrontEnd, AppEnd, BackendDB. Installation, Activation (Central Admin and Site Feature) all work fine.

However when punch "Check Access" I get;

http://www.oururl.com/_layouts/AccessChecker/CheckUserAccess.aspx

The website declined to show this webpage
    HTTP 403  

        Most likely causes:
        This website requires you to log in.

What you can try:
    Go back to the previous page.

Have tried as a Full Control account, Farm Admin account etc - still the same.

Thanks for your help.

Aaron

 

 

 

Aug 31, 2009 at 9:51 AM

Hi,

I tried the latest changeset 24736 and get the same error like Aaron (anikan).

Our configuration is MOSS 2007, SP2, June CU, English + German MUI.
The website I added this webpart to is based on German template.
I just tried an English template and the error persists.

The servername is different from the URL used to access the site.

Regards

Martin

Aug 31, 2009 at 1:34 PM

Same here, and we have SP 2, everything on a single server except the DB, the UI an templates are all English.

I rely very much on your useful tool and thus would highly appreciate a quick fix or workaround.

Best,
- Kian

Sep 16, 2009 at 7:40 AM

Bump.

Just wandering if there was any feedback on this issue.

Sep 16, 2009 at 7:42 AM

Unfortunately not.

Coordinator
Sep 16, 2009 at 7:51 AM

Sorry everyone, I've been pressed for time and haven't been able to look into this yet, but I haven't forgotten you all!

Tom.

Sep 16, 2009 at 10:37 AM

Hello,

I have also the same problem on one farm with 2 servers configured in Load Balancer.
Each time I click on the button 'Check access' I receive a 403 Forbidden error even with a farm or a site collection admin account.

However on a single server installation, I don't have this issue. Here a site collection admin can perform this operation without any problems.

Best regards,

Hervé

Sep 28, 2009 at 8:06 AM

Hello,

Any news regarding this issue ?

Best regards,

H.

Nov 13, 2009 at 9:53 PM

I think this is same issue as here: http://accesschecker.codeplex.com/Thread/View.aspx?ThreadId=68843

I think you'll get a 403 or the issue described in the other discussion depending on whether WSS_WPG has write access to

\Program Files\Common Files\Microsoft Shared\Web Server Extensions\wpresources\AccessCheckerWebPart\1.0.0.0__943c90ea94e8d758

At least that's what happens on my system. 

Does your View Permission Inheritance work OK?  Can you get to the Check User Access form to fill in the user name and access level, then the error happens when you click the Go button?

Nov 27, 2009 at 8:26 AM

Sorry for the late answer and thanks for yours.
So to answer to your question, yes the 'View permission inheritance' works ok but I'm sitll not able to use the check access feature for one user.
Each time I click on the button 'Check access', I receive this error message :

The process cannot access the file 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\wpresources\AccessCheckerWebPart\1.0.0.0__943c90ea94e8d758\LogFile_20091127_092136.log' because it is being used by another process.

Even by giving access to everyone in write, I still receive the error message.
Any idea of how I can solve this issue ?

Feb 5, 2010 at 11:21 AM
Edited Feb 5, 2010 at 11:22 AM

I just tried this tool on two servers - on a production server I get this error. On my development server where I can debug, it works fine. Figures.

I can confirm the 403 error comes from permissions to write to the log file. Even after granting the WSS_WPG group access, it still shows access denied using sysinternals processmonitor. I hacked the code to force the log path to the Temp folder so it had permssions to write, and then got the error in the http://accesschecker.codeplex.com/Thread/View.aspx?ThreadId=68843 that rknorp referenced. I then hacked the code again to write errors to the SharePoint trace logs instead of to a private log file and finally got the real underlying error which was:

Error In CreateChildControls: System.NullReferenceException: Object reference not set to an instance of an object.
at TomShirley.WebParts.AccessChecker.AccessCheckerInputForm.CreateChildControls()
at System.Web.UI.Control.EnsureChildControls()
at TomShirley.WebParts.AccessChecker.AccessCheckerInputForm.get_GenerateTree()
at TomShirley.WebParts.AccessChecker.AccessCheckerWebPart.CreateChildControls()

Error In OnPreRender: System.NullReferenceException: Object reference not set to an instance of an object.
at TomShirley.WebParts.AccessChecker.AccessCheckerInputForm.CreateChildControls()
at System.Web.UI.Control.EnsureChildControls()
at TomShirley.WebParts.AccessChecker.AccessCheckerInputForm.get_AccessLevel()
at TomShirley.WebParts.AccessChecker.AccessCheckerWebPart.ConfigureControls()
at TomShirley.WebParts.AccessChecker.AccessCheckerWebPart.OnPreRender(EventArgs e)

 

Oct 7, 2010 at 9:32 PM
Edited Oct 7, 2010 at 9:34 PM

I found I had to fix three things to get this to work on my development system.  I haven't tried it on a production system yet. 

I used the source for Version 1.3.

1. In Common.cs, method GetUserListPermissions uses reflection to access a private method in SPUtility called GetPermissions.  One of the service packs, hotfixes, or Search Server 2008 Express, adds 2 new overloads for GetPermissions, so GetMethod("GetPermissions", bindingFlags) fails with an AmbiguousMatchException.  The call to GetMethod is around line 136.  I changed it to:

                MethodInfo getPermissions =
                    typeof(SPUtility).GetMethod("GetPermissions",
                        BindingFlags.NonPublic |
                        BindingFlags.Public |
                        BindingFlags.Instance |
                        BindingFlags.InvokeMethod |
                        BindingFlags.Static,
                        null,
                        new System.Type[]{typeof(SPUserToken), typeof(ISecurableObject)},
                        null);

2. The logging code in ExceptionHandler.cs tries to write to the Event log using EventSourceName = "AccessCheckerWebPart".  It fails to create the EventSourceName with a permissions denied error.  I edited the registry to add the source name.  See http://support.microsoft.com/kb/329291, and use AccessCheckerWebPart instead of TEST as the key name in step 5.


3. Like paulhickman, I hacked the code to write the log file to the system temporary directory.  Around line 918 of AccessCheckerWebPart.cs, I changed

GenericExceptionHandler.LogPath = GetClassResourceFilePath(); 

to

GenericExceptionHandler.LogPath = System.IO.Path.GetTempPath();


 Not the best solution, I know.  I'll change it to write to the Sharepoint trace log, someday...

Oct 28, 2010 at 3:56 PM

Any update on this issue - I've just run into it, and I have a user breathing down my neck to get it fixed. I don't really feel comfortable editing the source code, but it doesn't look like I've got much choice.

May 5, 2011 at 3:11 PM

Can someone please recompile the source code with this fix?

 

               MethodInfo getPermissions =
                    typeof(SPUtility).GetMethod("GetPermissions",
                        BindingFlags.NonPublic |
                        BindingFlags.Public |
                        BindingFlags.Instance |
                        BindingFlags.InvokeMethod |
                        BindingFlags.Static,
                        null,
                        new System.Type[]{typeof(SPUserToken), typeof(ISecurableObject)},
                        null);

Thank you
Feb 11, 2013 at 4:33 AM
Another 'one-hit wonder' that disappoints. Complete with a "haven't got time" post followed by a vanishing act.

Ah, the sheer beauty of CodePlex.

\cbf

P.S. Does anyone else see the obvious irony of a program that checks access but doesn't have the access to do the checking?
Mar 5, 2013 at 2:52 AM
Edited Mar 5, 2013 at 2:58 AM
This project hasn't been touched in years. I've since changed jobs and haven't pushed this project along. Sorry to dissapoint anyone that was waiting for me to update and fix any outstanding issues.

@cfernald
If you're upset and need things fixed, do everyone a favor - don't whinge, fork the code and make a new version.

This was never a one-hit wonder from the get go. It was a neat little tool that you got for free and had the source code. It's as much an artifact of my journey learning to program against SharePoint than anything else.

I shared this to help people out. It worked for what I needed and so it was shared. Your complaint isn't realistic. If the originator isn't around any more you take the code and make it your own. You've missed the beauty of open source all-together...

FYI:
Looks like someone has ported it to 2010:
http://sdssharepointlibrary.codeplex.com/
Mar 5, 2013 at 3:03 AM
Yeah!