Re: [Repoze-dev] repoze.what-pylons question

[Iain Duncan]

On Wed, 2009-09-16 at 10:55 +0200, Douglas Mayle wrote:
> I'm not exactly sure, but I've done some similar things which have  
> worked, so I might be able to help out.  First of all, instead of  
> using default, you should probably be using __call__, like in:
> http://projects.mayle.org/hg/DVDev/file/c0c8da51a663/dvdev/controllers/mercurialgateway.py#l44

I had that thought too, but when I used call, failing the predicate
meant that the wsgi controller returned nothing and I got an exception
( and not a 403 ) about the wsgi controller returning nothing. What did
work with __call__ was manually going:

in_group('admin').check_authorization()

which raises the right exception, but then I would have to roll the
error handling myself.

> 
> But what's more likely causing the problem is using the protect_action  
> instead of ControllerProtector, like in:
> https://source.openplans.org/hg/communityalmanac/file/d5eaab92ec5c/communityalmanac/controllers/admin.py
>  
> #l20

I though of that too, and even weirder, protecting the wsgi controller
with ControllerProtector didn't do anything! Mind you I couldn't use the
decorator because we have to deploy on py2.5.

Thanks for the tips though,
Iain


___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze.what-pylons question

[Douglas Mayle]

I'm not exactly sure, but I've done some similar things which have  
worked, so I might be able to help out.  First of all, instead of  
using default, you should probably be using __call__, like in:
http://projects.mayle.org/hg/DVDev/file/c0c8da51a663/dvdev/controllers/mercurialgateway.py#l44

But what's more likely causing the problem is using the protect_action  
instead of ControllerProtector, like in:
https://source.openplans.org/hg/communityalmanac/file/d5eaab92ec5c/communityalmanac/controllers/admin.py
 
#l20

Douglas Mayle

On Sep 16, 2009, at 9:14 AM, Iain Duncan wrote:

> Hi folks, not sure if this should be on pylons or here. I'm using the
> repoze.what pylons quickstart code, and I'm having problems with the
> fact that when @protect_action fails, it tries to call the login  
> action
> *for the current controller*. This is causing me pain when my  
> controller
> is a wsgi wrapper ( to a bfg app ) because I have routes that gobble  
> all
> sub paths and pass them on to the bfg app. So instead of /login  
> going to
> the route controller, it gets eaten up. I have hacked around it by
> having routes rules like so:
>
> map.connect('/admin', controller='admin', path_info='/', )
> # need next rule else third admin rule will catch /admin/login
> map.connect('/admin/login', controller='root', action='login')
> map.connect('/admin/ 
> {path_info:.*}',controller='admin',action='default' )
>
> but it doesn't seem so elegant. Can anyone tell me why the following
> tries to call /admin/login and not the root /login, and how to change
> that behaviour.
>
> ( here's the controller in question ):
>
> # longhanded way of wrapping dram so we can use repoze.what decorators
> class AdminController(BaseController):
>def __init__(self, *args, **kwargs):
>BaseController.__init__(self, *args, **kwargs)
>self.dram = DramApp(package=ymh.model, global_config=config)
>
>@protect_action(has_permission('administrate')
>def default(self, environ):
>response = self.dram(environ, self.start_response)
>return response
>
> So in the above when the protect_action fails, it tries to take me
> to /admin/login, which I don't want.
>
> let me know if this should have gone to pylons!
> iain
>
> ___
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org
> http://lists.repoze.org/listinfo/repoze-dev

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] repoze.what-pylons question

[Iain Duncan]

Hi folks, not sure if this should be on pylons or here. I'm using the
repoze.what pylons quickstart code, and I'm having problems with the
fact that when @protect_action fails, it tries to call the login action
*for the current controller*. This is causing me pain when my controller
is a wsgi wrapper ( to a bfg app ) because I have routes that gobble all
sub paths and pass them on to the bfg app. So instead of /login going to
the route controller, it gets eaten up. I have hacked around it by
having routes rules like so:

map.connect('/admin', controller='admin', path_info='/', )
# need next rule else third admin rule will catch /admin/login
map.connect('/admin/login', controller='root', action='login')
map.connect('/admin/{path_info:.*}',controller='admin',action='default' )

but it doesn't seem so elegant. Can anyone tell me why the following
tries to call /admin/login and not the root /login, and how to change
that behaviour.

( here's the controller in question ):

# longhanded way of wrapping dram so we can use repoze.what decorators
class AdminController(BaseController):
def __init__(self, *args, **kwargs):
BaseController.__init__(self, *args, **kwargs) 
self.dram = DramApp(package=ymh.model, global_config=config)

@protect_action(has_permission('administrate')
def default(self, environ):
response = self.dram(environ, self.start_response)
return response

So in the above when the protect_action fails, it tries to take me
to /admin/login, which I don't want.

let me know if this should have gone to pylons!
iain

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev