Client security bug (WAS: Fetch Specifications defined in the .eomodel)
Client security bug (WAS: Fetch Specifications defined in the .eomodel)
- Subject: Client security bug (WAS: Fetch Specifications defined in the .eomodel)
- From: Florijan Stamenkovic <email@hidden>
- Date: Sun, 17 Feb 2008 10:43:38 -0400
Dave,
On Feb 16, 2008, at 12:12, David Avendasora wrote:
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.
Yes, this is my impression too. Well, good to know.
And regarding the root of this all, the SQL in your fetch spec, I
suppose then the only way to execute such a fetch spec is with
EOUtilities.objectsWithFetchSpecificationAndBindings(EOEditingContext
ec, String entityName, String fetchSpecName, NSDictionary bindings).
So, no SQL based fetch specs on the client then! I suppose that to
some degree makes sense regarding security, if you could use an SQL
based fetch spec constructed on the client side, there'd be no way to
control what sort of SQL you could put in, whereas programatic
EOFetchSpecs can only do so much...
In that sense the possibility to retrieve SQL based specs through EO
based RMI is a security hole. Maybe we should submit a bug report?
Flor
_______________________________________________
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