Re: [Repoze-dev] repoze.what-pylons question
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
Re: [Repoze-dev] Is it possible to integrate repoze.plone and Pylons in one WSGI application?
It depends on how basic your CMS needs are. The Pylons Book contains a simple CMS called SimpleSite that you could probably integrate, if your needs were light. http://pypi.python.org/pypi/SimpleSite/0.3.0 http://pylonsbook.com/en/1.0/starting-the-simplesite-tutorial.html http://pylonsbook.com/en/1.0/simplesite-tutorial-part-2.html http://pylonsbook.com/en/1.0/simplesite-tutorial-part-3.html Doug On Jun 18, 2009, at 2:03 PM, Edwin Chu wrote: Hi all I am working on a project using Pylons and I need to add CMS functionality to that Pylons project. I am looking for some existing CMS solution that can be integrated into Pylons WSGI pipeline. The requirements of the CMS are basic, like editing page content, menu and probably handling images. repoze.plone is the only CMS I can find using WSGI standard. Is it possible to add repoze.plone to Pylons's WSGI pipeline so that they can be ran in the same process? I googled a while but nothing useful was found. Thanks Regards Edwin ___ 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] [issue85] Repoze.who should support salted hashes for the sqlauthenticator
Douglas Mayle doug...@mayle.org added the comment: Any comments for me? Anything I need to do to get this accepted? I think it's pretty thorough, but I'm open to any criticism... __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue85 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Combining registration with login...
Hey everybody, I'm using repoze.who for authentication, and I've got the major part of it setup. Login works, as does logout. I just finished writing user registration, and was wondering if there was a way that I could automatically log the user in on successful signup? I'm currently using the redirectingform plugin and the sql authenticator. Will I have to write my own custom plugin, or is there something I can do out of the box? Thanks, Douglas Mayle ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Combining registration with login...
Thanks, that worked a treat! I've got comments in my code pointing to the issue. Hopefully it will be fixed for the next release... Doug On May 22, 2009, at 3:54 PM, Gustavo Narea wrote: Hi, Douglas. Unfortunately it's not well supported. Here you'd find how to do it for the time being: http://bugs.repoze.org/issue58 Cheers. - Gustavo. Douglas said: Hey everybody, I'm using repoze.who for authentication, and I've got the major part of it setup. Login works, as does logout. I just finished writing user registration, and was wondering if there was a way that I could automatically log the user in on successful signup? I'm currently using the redirectingform plugin and the sql authenticator. Will I have to write my own custom plugin, or is there something I can do out of the box? Thanks, Douglas Mayle ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev -- Gustavo Narea xri://=Gustavo. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | ___ 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] [issue82] Add HashFormPlugin - JavaScript hashing
Douglas Mayle doug...@mayle.org added the comment:
I've commented on this patch on the mailing list, but wanted to make sure my
concerns were recorded here:
* `if cleartext_password.startswith('{SHA}'):`
The hashing system is entirely optional at the client level, so
you don't provide password protection for all clients.
* The challenge used for verification is the challenge supplied by the
client. This defeats entirely the point of a challenge. I see you do
some calculations to restrict the range of possible challenges (based
on time), but a challenge response only works if the challenge is
random and server supplied. If not, then it's vulnerable to pre-
computation...
* You're performing an HMAC with the challenge as the key. The
purpose of an HMAC is to provide authentication of the message in the
case of a shared private key. In this case, the key is public (as
it's sent over the wire) and that means that there is no difference
between this HMAC and a standard hash.
* In the case of a hashed password, you perform an HMAC of the hashed
password. In a standard hashed password system, the user must know
the clear text password in order to log in. The point of the hash is
to prevent authentication in the case of a database leak. In your
system, the hashed password is sufficient to login, and so you've
removed the protection that password hashing provides.
* While it's true that using a different key per request means that
attackers who sniff the HMAC won't be able to use rainbow tables to
compute the password from the HMAC, the passwords are still stored as
standard hashed passwords, and that means that a db leak leaves all of
your accounts compromised. With salted hashes, that is not true...
--
topic: +repoze.who
__
Repoze Bugs b...@bugs.repoze.org
http://bugs.repoze.org/issue82
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator
Douglas Mayle doug...@mayle.org added the comment: New version of the patch which also supports blowfish hashes when bcrypt is installed, and uses pycrypto on python 2.5 for sha256 support. This patch superseded the previous two patches. __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue85 __ repozewho_salted_hashes_with_bcrypt.diff Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator
Douglas Mayle doug...@mayle.org added the comment: Whoops, bad unittest passed through because I was testing in Python 2.5 __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue85 __ repozewho_salted_hashes_with_bcrypt.diff Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue71] repoze.who has problems with generator wsgi applications.
Douglas Mayle doug...@mayle.org added the comment: As repoze.who fails to handle the WSGI spec, and I'm supplying a working patch, I'm bumping up the priority... -- priority: bug - critical __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue71 __ issue71.diff Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue71] repoze.who has problems with generator wsgi applications.
New submission from Douglas Mayle doug...@mayle.org: If a WSGI application returns a generator expression, then default_challenge_decider in classifiers.py tries to call status.startswith, which blows up because status has not yet been decided (since the generator hasn't been called yet) -- messages: 173 nosy: douglas priority: bug status: unread title: repoze.who has problems with generator wsgi applications. __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue71 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue71] repoze.who has problems with generator wsgi applications.
Douglas Mayle doug...@mayle.org added the comment: The only way I can think to fix this is to create a new generator that wraps the previous one. It calls the wrapped generator once, caches that, and then yields that and any further responses. This allows the original generator to behave the way it did before, and repoze.who can take a look at the status code. -- status: unread - chatting __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue71 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
