• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Fetch Specifications defined in the .eomodel *FIXED*
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fetch Specifications defined in the .eomodel *FIXED*


  • Subject: Re: Fetch Specifications defined in the .eomodel *FIXED*
  • From: David Avendasora <email@hidden>
  • Date: Sat, 16 Feb 2008 11:12:15 -0500


On Feb 16, 2008, at 10:22 AM, Florijan Stamenkovic wrote:

[2008-02-15 16:53:14 EST] <WorkerThread0> Server exception: The fetchSpecification <SNIP/> was not allowed to execute on the server.  If your application needs to execute this method, the security needs to be relaxed by implementing the delegate method distributionContextShouldFetchObjectsWithFetchSpecification

The original server-side calls for this were catching the error and just returning null without putting anything in the log.

Interesting... Do you know exactly at which point in your code was this error generated? Was in on the line where you try to retrieve the fetch spec object from the model on the server side? When you try to return that fetch spec over to the client?

The funny  thing is that it doesn't actually generate an error. I got that message in the log when I used a logging statement to look at the FetchSpecification immdiately after pulling it from the model:

EOFetchSpecification fs = (EOFetchSpecification) distributedObjectStore().invokeStatelessRemoteMethodWithKeyPath(
"session", 
"clientSideRequestGetFetchSpecification", 
new Class[] {String.class, String.class }, 
new String[] { "USDACalories", "NutritionElementType" }); 
NSLog.out.appendln(fs);

Apperently calling editingContext().objectsWithFetchSpecification(fs) just returns null and doesn't raise an exception.


The funny thing is that I can call this FetchSpecification using the normal invokeRemoteMethod() method of EOCustomObject, but if I try to use the invokeStatelessRemoteMethodWithKeyPath() method of EODistributedObjectStore, then it throws the above error.

So, if I understand you well, now that you've removed the SQL from the spec, you can use also stateless RMI to get it?

Yep. I didn't change anything else.


And before that you could only retrieve it with EO based RMI?

Exactly!

This is really weird.

Tell me about it.

At first it seemed like a valid security precaution, but the more I think about it, the less sense it makes...

Especially when you can get around it by using EOCustomObject's invokeRemoteMethod(). Seems like maybe it was the beginnings of something, then abandoned and left in.

Dave
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Client security bug (WAS: Fetch Specifications defined in the .eomodel)
      • From: Florijan Stamenkovic <email@hidden>
References: 
 >Re: Fetch Specifications defined in the .eomodel (From: David Avendasora <email@hidden>)
 >Re: Fetch Specifications defined in the .eomodel (From: Florijan Stamenkovic <email@hidden>)
 >Re: Fetch Specifications defined in the .eomodel (From: David Avendasora <email@hidden>)
 >Re: Fetch Specifications defined in the .eomodel (From: Florijan Stamenkovic <email@hidden>)
 >Re: Fetch Specifications defined in the .eomodel *FIXED* (From: David Avendasora <email@hidden>)

  • Prev by Date: Re: Fetch Specifications defined in the .eomodel *FIXED*
  • Next by Date: Re: WebObjects 5.4.1 and NPE when registering WebServices classes
  • Previous by thread: Re: Fetch Specifications defined in the .eomodel *FIXED*
  • Next by thread: Client security bug (WAS: Fetch Specifications defined in the .eomodel)
  • Index(es):
    • Date
    • Thread