This is a migrated thread and some comments may be shown as answers.
403 problem in Web Part using Object Data Source
5 Answers 51 Views
This is a migrated thread and some comments may be shown as answers.
Joe
Top achievements
Rank 1
Joe asked on 15 Jun 2009, 06:44 PM
Hi,

I am having a very strange problem and I'm not sure what is causing it.

I have built a WSS 3.0 web part that implements a Rad Scheduler (2009.1.527.35). I have implemented custom Object Data Sources exactly as described here: http://www.telerik.com/help/aspnet-ajax/schedule_databindingusingthedatasourceproperty.html

When I deploy the web part, the browser displays a 403 error. To get around this error I can do the following:

1. Open web.config
2. Change something - it can be anything, even just deleting a random character
3. Save the file
4. Site will error out - if I've deleted something important in the web.config
5. Undo changes to web.config - resave
6. Site will come back up and the web part will display

At this point everything will work fine with the scheduler control. All methods in the object data sources will work properly.

If at any time there is an IISRESET run on the server or if I recycle the app pool for this site, the page will go back to the 403 error.

I have narrowed it down to when the object data source is being bound to the scheduler control in my CreateChildControls() method that is causing the issue. I tried moving that code out of the CreateChildControls() and moving it to the RenderWebPart(), but I get a different error, "DataKeyField, DataSubjectField, DataStartField and DataEndField are required for databinding". Which makes sense.

I have also tried to add the object data sources in both OnInit() and CreateChildControls() and the 403 error appears the same for both variations.

From what I can gather, it seems the scheduler control is trying to databind during the CreateChildControls() method and somehow it doesn't have permission to access the object data sources. To ensure it wasn't any custom code in my object data sources, I created a test Select method with no code and bound to that. I had the same problem. Now I also know the 403 is getting thrown before any of my object data source code is actually hit.

I'm not sure if it matters that I am adding the object data sources dynamically to the page or not? Or whether it matters that I am adding those and the scheduler to the page at the same time?

I'm also not sure if I need to add something to my object data source classes to make them accessable from the web part. I tried the AllowPartiallyTrustedCallersAttribute without success.

Here's the setup of my solution:
1. All files are under 1 project - so when I build, I get 1 assembly
2. All classes are using the same namespace (custom)
3. 1 class file that handles the web part code - inherits from Microsoft.SharePoint.WebPartPages.WebPart
4. 1 class file that handles all my custom toolpane options - inherits from Microsoft.SharePoint.WebPartPages.ToolPart
5. All other class files have no inheritance

Another thought I have is that because my custom data source classes have no inheritence to anything in SharePoint, when they are first loaded SharePoint doesn't know they exist under the context? But I did put the proper SafeControl entry in the web.config for the entire namespace (which includes my custom classes). So that one seems unlikely.

I have also followed all the online documentation on adding the telerik customizations to the web.config. I have set my SP trust level to "Full" and I even tried creating a custom CAS file, specifying my DLL. Neither of those solve my problem. My SP site is running under Basic authentication. (I tried integrated, without success)

Has anyone ever tried building a web part using RadScheduler and Object Data Sources? Any ideas or possible solutions to try are appreciated.

Thanks.

5 Answers, 1 is accepted

Sort by
0
Atanas Korchev
Telerik team
answered on 16 Jun 2009, 12:25 PM
Hello Joe,

Unfortunately we cannot tell what the problem is based on your description. RadScheduler and all telerik controls require higher trust level than the default in order to work in MOSS. That's why we recommend deployment in GAC or changing the trust level of the MOSS web site at least to Medium.

Have you tried binding your object data source to any other control? Have you explored the event log to see if there is any exception which may have caused the 403 error?

All the best,
Albert
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
0
Joe
Top achievements
Rank 1
answered on 16 Jun 2009, 01:30 PM
Yes, I have done both of those. The web part is in the GAC.

I first tried creating my own CAS file, specifying my DLL, without success. I have tried all trust levels, without success.

The error log just gives me a basic error without detail:

Event code: 4011

Event message: An unhandled access exception has occurred.


Which doesn't tell me anything more than the browser error does.

I was reading a post on a completely different topic yesterday describing how in MOSS an impersonated user cannot access resources in satellite assemblies. I can set impersonation = false in my web.config and it fixes my problem. However, doing that is simply by passing my problem and causes others in my site.

My latest theory on my problem is that either the object data source classes or the skins embeded in the telerik.web.ui dll are not being allowed to be accessed by an impersonated user. Is there anything that I can put in my web.config that will ensure MOSS has the proper impersonated access to these resources?

Also, do you have any samples of a MOSS web part implementing Rad Scheduler using Object Data Sources? I might be able to deduce something from that? A sample web.config file for this scenario would be helpful as well.

Thanks.
0
Atanas Korchev
Telerik team
answered on 22 Jun 2009, 07:37 AM
Hello Joe,

All files deployed in GAC should by default run in full trust.
Embedded skins are implemented as web resources which as far as we know should work as expected without any impersonation problems. To locate the problem is you can try binding your object datasource to a regular GridView or DataGrid control. If the problem is in the objects being requested it should manifest itself in this case as well.

Regards,
Albert
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
0
Joe
Top achievements
Rank 1
answered on 23 Jun 2009, 06:25 PM

Albert,

 

I was able to identify my problem was somewhere with my custom classes used by the object data source. So I have completely re-coded everything to bind to a generic list. Now all code is wrapped up in the 1 class. That fixed my original 403 error.

 

However, I am now experiencing a new 403 error. I have the start in advanced form settings for both insert and update set to false. I am able to update or insert from the quick forms with no problem. When I click the 'options' link to get to the advanced forms, my page refreshes, and I get a 403 error. I have also tried to implement a RadAjaxManager to avoid the refresh and I get the same 403 error (actually a javascript error saying the same thing). I have implemented this example almost exactly, minus resources and recurrance: http://demos.telerik.com/aspnet-ajax/scheduler/examples/bindtolist/defaultcs.aspx

 

Any ideas on what could cause this?

 

Thank you.

0
Dimitar Milushev
Telerik team
answered on 24 Jun 2009, 03:55 PM
Hi Joe,

The most common reason for 403 Errors in Sharepoint are permission issues, but SharePoint has the bad habit to hide problems behind totally unrelated 'friendly' error messages. A colleague of mine has explained how to try to get more info about the exact reason in this forum post. Additionally, as suggested by this blog post you can try FileMon to see if there is a problem with file access permissions as the "unhandled access exception" suggests.

There are also a few more things you can try. Sometimes surrounding your code with try-catch blocks and outputting the message/stack trace of the catched exception or any inner exceptions may provide the needed info. You can also try removing/commenting any Databinding code leaving only the Scheduler. Simply set the four required Data*Field properties and you should be able to show the Scheduler and go to the advanced form.

Best wishes,
Dimitar Milushev
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
Asked by
Joe
Top achievements
Rank 1
Answers by
Atanas Korchev
Telerik team
Joe
Top achievements
Rank 1
Dimitar Milushev
Telerik team
Share this question
or