(on Thursday, 02 April 2009, 01:12 PM -0700):
> That makes sense - thanks for the explanation.
>
> For this example, I will be using Dojo on the front-end
> (dojo.rpc.JsonService) to consume the services exposed by the "service
> layer" classes. This indeed brings up the issue of securing these
> services...
>
> My first thought is to pass the userId as an argument in the
> dojo.rpc.JsonService call to the service, check if that userId has
> permissions for the requested action/method, and continue from there.
> Clearly this is faulty because the dojo.rpc.JsonService submits using HTTP
> Post which could very easily be spoofed should one so desire.
>
> My second thought was to capture the user's auth info in the Controller
> action and pass it into where the Zend_Json_Server resides and verify
> permissions there before allowing access to the server...?
>
> What is your currently used best practice for this?
The cool part about JSON-RPC is that it's happening in the same domain,
using HTTP... so you have access to the session. On a project I've been
working on recently, we leveraged this -- we use
Zend_Auth::hasIdentity() and Zend_Auth::getIdentity() to determine if
the user is logged in, and then to grab the identity for later ACL
checks. We've also created standard "error" payloads that can report the
fact that the person is either not logged in or has insufficient ACLs so
that the client can the present a login form or an error dialog.
It also means we only need to pass the parameters necessary for the
called method -- the identity is part of the session already.
> Matthew Weier O'Phinney-3 wrote:
> >
> > -- Erik Olof Wahlstrom <ewahlstr@gmail.com> wrote
> > (on Wednesday, 01 April 2009, 05:01 PM -0700):
> >>
> >> Thanks for your response, however I had reviewed my code at LEAST ten
> >> times
> >> before I submitted my question to the mailing list... Finally, I
> >> resorted
> >> to copying my class to a new name and then, starting at the bottom,
> >> deleting
> >> each method from the class. I was expecting to pinpoint which method was
> >> causing the problem.
> >>
> >> As it turned out, I continued deleting methods all the way to my
> >> __construct
> >> - even then, the code still gives the same error. Lightbulb moment
> >> ensues -
> >> my class is extending Zend_Db_Table and the error is obviously being
> >> thrown
> >> in regards to some code in that class (or more accurately
> >> Zend_Db_Table_Abstract).
> >>
> >> I can see that this brings up a whole assortment of issues in regards to
> >> the
> >> Zend_Json_Server - for example, a lot of return types from
> >> Zend_Db_Table_Abstract are obviously not types that could be handled
> >> natively by JavaScript.
> >>
> >> So I guess the question has morphed into the following: how can I expose
> >> a
> >> class through Zend_Json_Server that extends classes such as
> >> Zend_Db_Table?
> >
> > Simple answer: don't.
> >
> > Longer answer: create a "service layer" for your models. This layer will
> > consume your Zend_Db_Table objects and create return values that your
> > server classes can then safely expose. For example, they might case
> > Zend_Db_Table_Rows to arrays before returning them, or detect when no
> > results were found and return a boolean false.
> >
> > It's typically a bad idea to use Zend_Db_Table directly with the server
> > classes because doing so exposes methods such as delete() and save() --
> > you're basically giving unfettered access to the database via your
> > service layer, without any validation whatsoever. You should only expose
> > what's absolutely necessary, and ensure that the data provided is valid
> > before you perform any DB operations.
> >
> >> Matthew Weier O'Phinney-3 wrote:
> >> >
> >> > -- edub <ewahlstr@gmail.com> wrote
> >> > (on Tuesday, 31 March 2009, 12:05 PM -0700):
> >> >>
> >> >> I am working with creating a Zend_Json_Server and setting some classes
> >> >> like
> >> >> so:
> >> >>
> >> >> $server = new Zend_Json_Server();
> >> >>
> >> >> $server->setClass('MyClass', 'mynamespace');
> >> >>
> >> >> When I try to get the smd for this, Zend_Reflection throws the
> >> following
> >> >> error about my class:
> >> >>
> >> >> Zend_Server_Reflection_Exception Object
> >> >> "Variable number of arguments is not supported for services (except
> >> >> optional
> >> >> parameters). Number of function arguments must currespond to actual
> >> >> number
> >> >> of arguments described in a docblock."
> >> >>
> >> >> I understand exactly what this means and have gotten this code to work
> >> >> using
> >> >> some less complex classes - however, on the class I am attempting to
> >> >> expose
> >> >> right now, I just cannot find where I might have a discrepancy in my
> >> >> docblock.
> >> >>
> >> >> It would be extremely usefull if the Zend_Server_Reflection threw an
> >> >> exception that could help pinpoint which method it was having problems
> >> >> with... Has anyone had a similar experience?
> >> >
> >> > Wow... I'm not sure how that exception message could be any more clear,
> >> > actually.
> >> >
> >> > What it's saying is that there is a discrepancy with the number of
> >> > arguments defined in the function call and those in its corresponding
> >> > docblock. As an example:
> >> >
> >> > /**
> >> > * Do something
> >> > *
> >> > * @param string $foo
> >> > * @return string
> >> > */
> >> > public function doSomething($foo, $bar)
> >> > {
> >> > }
> >> >
> >> > In this example, your function requires 2 parameters -- but your
> >> > docblock is only reporting one of them. This is an issue as we cannot
> >> > infer any type information on the second parameter -- and thus an
> >> > exception is raised.
> >> >
> >> > The opposite is also true:
> >> >
> >> > /**
> >> > * Do something
> >> > *
> >> > * @param string $foo
> >> > * @return string
> >> > */
> >> > public function doSomething()
> >> > {
> >> > }
> >> >
> >> > In this case, you may be using func_get_args() to process variable
> >> > numbers of arguments in your method. Being a good developer, you've
> >> > documented the fact that you might accept a parameter. However, because
> >> > there is no corresponding _real_ parameter in the method definition,
> >> > reflection is unaware of it, leading to a mismatch between the two.
> >> > Again, an exception is raised.
> >> >
> >> > Both situtations are summed up nicely in the last sentence of that
> >> > exception message:
> >> >
> >> > "Number of function arguments must correspond to actual number of
> >> > arguments described in a docblock."
> >> >
> >> > --
> >> > Matthew Weier O'Phinney
> >> > Software Architect | matthew@zend.com
> >> > Zend Framework | http://framework.zend.com/
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Zend_Server_Reflection_Exception-be-more-specific-with-your-feedback...-tp22807177p22835017.html
> >> Sent from the Zend Web Services mailing list archive at Nabble.com.
> >>
> >
> > --
> > Matthew Weier O'Phinney
> > Software Architect | matthew@zend.com
> > Zend Framework | http://framework.zend.com/
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Zend_Server_Reflection_Exception-be-more-specific-with-your-feedback...-tp22807177p22856101.html
> Sent from the Zend Web Services mailing list archive at Nabble.com.
>
--
Matthew Weier O'Phinney
Software Architect | matthew@zend.com
Zend Framework | http://framework.zend.com/
没有评论:
发表评论