That's security. I can see how the vanilla security system cannot handle this; I recommend extending SecurityFilter so it calls a checkPermissions() method or something on the action.
HTH, David Am 03.07.2007 um 14:51 schrieb Shoan Motwani: > We have a similar situation in our project. We need to validate > whether the logged in user can edit/delete a record. I am thinking > that a callback in the routing containing the id of the record > ( www.example.org/edit/123) would be the best place to validate > whether the user can actually mess with the record. > > Is there a better way? > > Peace, > Shoan. > > > On 28-Jun-07, at 3:26 AM, David Zülke wrote: > >> The problem I see with this is that it happens too early, outside the >> normal validation process. OTOH, it's probably justified as every >> request goes to such an "object", hence a "validation" in a routing >> callback could very well be justified. >> >> A good example of a situation where, in my opinion, validating >> something in a routing callback is okay is when you have a service >> that allows people to register their own subdomains: >> >> <route name="subdomain" pattern="^(userdomain:[^.]+).myservice.com$" >> callback="UserSubdomainRoutingCallback" /> >> >> because otherwise, you would have to validate the subdomain in every >> single action, and maybe even take other measures (such as store the >> subdomain somewhere for later use, gather info about that account, >> and so on). >> >> >> David >> >> >> >> Am 27.06.2007 um 23:44 schrieb Noah Fontes: >> >>> Afternoon, >>> >>> Have you taken a look at Veikko's CMS application? He uses a pretty >>> unique >>> method to determine whether some object is valid. What he's done is >>> set up a >>> routing callback that checks the id parameter of the request data >>> and grabs >>> the correct item from the DB and sends it to Request or returns >>> false if it >>> doesn't exist. >>> >>> I'm not sure how 'correct' this is (it'd have to be in your global >>> namespace, >>> and if you have to do any manipulation/validation of request data >>> besides >>> checking to see if it exists in the database, this probably isn't >>> the way to >>> go), but it might be worth a try. >>> >>> The major upside to this is that you can specify the same routing >>> callback to >>> check/validate multiple routes -- plus it forwards to the 404 >>> action by >>> default upon returning false in the method. >>> >>> I definitely like the idea of setting the proper view in handleError >>> () too >>> (obviously Veikko's idea is only for the 404 part :). +1 for that >>> as well. >>> >>> Regards, >>> >>> Noah >>> >>> On Wednesday 27 June 2007 07:25:59 Van Daele, Koen wrote: >>>> Ok, thx for the feedback. >>>> >>>> Returning the global 404 view does seem better than having a >>>> 404View per >>>> action (since almost every action could have a itemNotFound error. >>>> >>>> Koen >>>> >>>>> -----Oorspronkelijk bericht----- >>>>> Van: [EMAIL PROTECTED] >>>>> [mailto:[EMAIL PROTECTED] Namens David Zülke >>>>> Verzonden: woensdag 27 juni 2007 12:43 >>>>> Aan: Agavi Users Mailing List >>>>> Onderwerp: Re: [Agavi-Users] Handling errors >>>>> >>>>> Hi Koen, >>>>> >>>>> I think multiple Views are the way to go here. Your >>>>> NotFoundErrorView could then forward to the 404 action, for >>>>> example, so you don't have too much duplicate code. If your >>>>> 404 action is empty, i.e. just a view (which it should be), >>>>> then you could also return array >>>>> (AgaviConfig::get('actions.404_module'), AgaviConfig::get >>>>> ('actions. >>>>> 404_action')) from the action to make agavi use that view >>>>> instead of one related to the action itself. You can talk to >>>>> the validation manager (available from the container) inside >>>>> handleError() to find out which validator failed, and then >>>>> return the appropriate view name. >>>>> >>>>> >>>>> Hope that helps, >>>>> >>>>> David >>>>> >>>>> Am 27.06.2007 um 12:18 schrieb Van Daele, Koen: >>>>>> Hi all, >>>>>> >>>>>> I'm trying to decide how to go about handling crud errors. From >>>>>> the >>>>>> IRC logs I've gathered that the best approach would be to have: >>>>>> - An InputView >>>>>> - An ErrorView that uses the InputTemplate >>>>>> - A SuccessView that redirects to >>>>>> >>>>>> The problem I'm having is that there are different types of >>>>> >>>>> errors. >>>>> >>>>>> E.g >>>>>> take a simple Book.Edit action. The first possible error is a >>>>>> user >>>>>> trying to edit a book that doesn't exist (should return a 404 >>>>>> or a >>>>>> 'sorry, this book doesn't exist' page. The second type of >>>>> >>>>> error is a >>>>> >>>>>> user entering incorrect data (a validation error) that show >>>>> >>>>> the input >>>>> >>>>>> template again. A third possible error might be that there's a >>>>>> concurreny issue (should e.g. tell the user to re-edit the >>>>> >>>>> record or >>>>> >>>>>> should ask them if they're sure they want to overwrite user >>>>> >>>>> z's edit). >>>>> >>>>>> Do you use different Error views (eg. InputErrorView, >>>>>> NotFoundErrorView, ConcurrencyErrorView)? Or do you set an >>>>> >>>>> attribute >>>>> >>>>>> in the action and then let the error view decide what to >>>>> >>>>> do? Are there >>>>> >>>>>> other options? >>>>>> >>>>>> Greetings, >>>>>> Koen >>>>>> >>>>>> _______________________________________________ >>>>>> users mailing list >>>>>> [email protected] >>>>>> http://lists.agavi.org/mailman/listinfo/users >>>>> >>>>> _______________________________________________ >>>>> users mailing list >>>>> [email protected] >>>>> http://lists.agavi.org/mailman/listinfo/users >>>> >>>> _______________________________________________ >>>> users mailing list >>>> [email protected] >>>> http://lists.agavi.org/mailman/listinfo/users >>> >>> -- >>> Noah Fontes >>> Cynigram Network Administrator >>> [EMAIL PROTECTED] >>> >>> _______________________________________________ >>> users mailing list >>> [email protected] >>> http://lists.agavi.org/mailman/listinfo/users >>> >> >> >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.agavi.org/mailman/listinfo/users > > > _______________________________________________ > users mailing list > [email protected] > http://lists.agavi.org/mailman/listinfo/users > _______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
