[web2py:28002] Re: Hacking the Windows version of web2py.py
Yes. On Aug 4, 5:03 pm, Crabby wrote: > Aha -- I think I need to tweak widget.pyc as well (to add the menu of > IP addresses), but knowing that all this stuff is in library.zip was > the piece I was missing. > > I assume I can just compile the corresponding ?.py (from the like- > versioned source) and replace the corresponding element(s) of library. > > Thanks, > scott > > On Aug 4, 5:34 pm, mdipierro wrote: > > > I do not know what changes you need to make but you can change the > > main.pyc in library.zip. > > > > In the source & Mac-standalone versions of web2py, one can (and I > > > did :)) change/replace the file web2py.py in order to modify the > > > server application. (In my case, I'm adding a list of server IPs to > > > choose from and spawning an extra process; the latter could presumably > > > be done elsewhere, but it is tied to the server running, so this way I > > > can easily start/stop it when the server starts/stops.) > > > > But in the Windows-standalone version, this file is not present > > > (presumably because it's functionality is baked into web2py.exe). > > > > So is there some way to make such modifications to the Windows- > > > standalone version? Maybe some kind of hook(s) into web2py.exe? I'd > > > even be willing to make a modified version of web2py.exe, but I don't > > > see the source for it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:28001] WIKI in Manual
Hi, I had troubles with images in Mnual so I went on to the wiki part
3.7. I am copying the code from the manual, but I seem to run into
errors that I don't understand so I can't correct them. Are these
examples outdated so I should try something else.
Jim
Error ticket for "wiki"
Ticket
127.0.0.1.2009-08-04.23-10-26.61d82cfb-2dca-49bc-9b42-3cb8e2cf210c
Error traceback
1.2.3.4.5.6.7. Traceback (most recent call last): File "gluon/
restricted.py", line 176, in restricted File "C:\web2py_win(2)\web2py
\applications\wiki/views/default/index.html", line 62response.write
('\r\n ',escape=False) ^SyntaxError: invalid syntax
In file: C:\web2py_win(2)\web2py\applications\wiki/views/default/
index.html
1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.61.62.63.64.65.66.
response.write('http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">\nhttp://www.w3.org/1999/xhtml"\n
xml:lang="',escape=False)response.write(T.accepted_language or 'en')
response.write('">\n \n',escape=False)response.write
(response.title or 'response.title')response.write('\n
\n \n \n \n \n ',escape=False)import
osresponse.write('\n
\n\n\n\n\n \n \n \n\n \n\n \n\n',escape=False)
title=response.title or 'response.title'response.write('
\n',escape=False)response.write(A(title, _href=URL
(request.application,'default','index')))response.write('\n
\n\n',escape=False)response.write
(response.subtitle or 'response.subtitle')response.write('
\n \n\n\n \n',escape=False)
response.write('/'.join
(['',request.application,request.controller,request.function]
+request.args))response.write('\n \n
\n\n \n
',escape=False)if response.menu_auth:response.write('\n
Authentication\n',escape=False)response.write
(MENU(response.menu_auth))response.write('\n
',escape=False)passresponse.write('\n',escape=False)if
response.menu:response.write('\nMain Menu
\n',escape=False)response.write(MENU
(response.menu))response.write('\n',escape=False)
passresponse.write('\n',escape=False)if
response.menu_edit:response.write('\nEdit This
App\n',escape=False)response.write(MENU
(response.menu_edit))response.write('\n
',escape=False)passresponse.write('\n\n
\n \n',escape
[web2py:28000] Re: How to set http "keep-alive" parameter?
since this fails with (as I recall) with a specific file, and a specific browser (mostly webkit based, e.g. either Chrome/Chromium, or Safari) Someone should identify a known failing file, and share for testing. Massimo: you will recall other issues cropped up before (e.g. pages not always displaying for you)... although this patch set Fran identified looks promising, I remember we thought so earlier this year too... so test,test, test... On Tue, Aug 4, 2009 at 7:13 PM, Fran wrote: > > On Aug 5, 1:10 am, 陶艺夫 wrote: > > You mean then the bug's gone in the newest version of CP? > > Hopefully > > > Can really CherryPy be used in a production environment? I'm a little > confused now. > > Works for me - either with Apache/WSGI or natively ona single-user > Win32 client. > > F > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27999] Re: r1045 breaks some upload fields
On 4 ago, 18:16, mdipierro wrote: > I believe this problem was fixed in 1.65.10. Am I wrong? > > Massimo > There is an instant I updated from the trunk (v1.65.11, r1156) and this time works well. Thank you Jose --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27998] Re: breadcrumb design
On Jul 17, 10:52 am, Alex Fanjul wrote: > I agree with you Richard, > In deed, in statusbar there is already a "kind of breadcrumb" but > wihtout links... > > A vote for this inbuild functionallity... > Otherwise, I bet that someone has a quick and simple idea to do this > with one function and getting the information from url app, controller, > function. hmm, doing it automatically from the URL might work for me if I plan it right. Does anyone else already have their own breadcrumb system? Richard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27997] Re: How to properly remove a user in Auth.
another issue I came across is that the deleted user can stay logged in with their previous session cookie. Is there an efficient way to get around this? Richard On Jul 19, 5:33 pm, Hans Donner wrote: > Keep in mind if you reference to this user in other tables as well > (your apps). If you make joins against the user table this may lead to > unwanted results in your app. > > If this is the case you perhaps only want to strip the roles and > permissions for this user. > > But this is more related to your app internals than it is demanded by auth. > > On Sun, Jul 19, 2009 at 07:28, mdipierro wrote: > > > It should be ok to just delete the user from the database. given the > > user id, you may also want to delete > > > db(db.auth_group.role=='user_%s'%id).delete() > > db(db.auth_membership.user_id==id).delete() > > > On Jul 18, 11:42 pm, Jason Brower wrote: > >> What is the proper way to remove a user with the Auth method? I could > >> just delete them from the database. But I don't know about all the > >> connection they may have. Is there something built in to auth for this? > >> Perhaps it should be part of their edit profile page? > >> Best Regards, > >> Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27996] Re: Fwd: My thoughts on web2py
> Yeah maybe a complete web2py 2 rewrite. With nice and better coding... I really REALLY hope not... web2py is already an incredibly useful web framework and is getting better each month with new features and bug fixes. IMO investing energy in a rewrite could split the community and would certainly set back the pace of development. And I also don't feel development is significantly constrained by backwards compatibility. Maintaining backwards compatibility is one of the core advantages of web2py that attracted me to it. Richard On Aug 5, 4:30 am, Pynthon wrote: > Yeah maybe a complete web2py 2 rewrite. With nice and better coding... > Alex Fanjul has a point IMO. > > On 4 aug, 20:15, Iceberg wrote: > > > Perhaps we will eventually have a web2py 2.0 in the way which Alex > > Fanjul suggests. > > > Meanwhile, we can take closer look into those "many times" of "due to > > backward compatibility" issue, and see what can be adjusted. We did > > that before at least for IS_STRONG. > > > This time, for example, the datetime.utcnow issue can be easily > > addressed by a request.utcnow, and keep request.now as is but > > obsolete. Oops, problem solved without breaking backward > > compatibility. > > > Regards, > > Iceberg > > > On Aug5, 1:55am, Alex Fanjul wrote: > > > > Massimo, > > > Many times I have seen that, due to backward compatibility, we are > > > forcing to write "messy" code in web2py applitacations. > > > Evenmore some issues will never fix in the right way bacause of that... > > > Won't you consider/planning to do a breakpoint with a major version > > > web2py 2.0? and solve such things? > > > > Python did it with 3.0, isn't it? > > > > Only out of curiosity, sorry if it's reduplicate question, regards, > > > Alex F > > > > El 04/08/2009 9:04, mdipierro escribió: > > > > > Changing now into utcnow would break backward compatibility. > > > > > I do agree with you that othen people may want to use > > > > > Field(,default=datetime.utcnow()) > > > > > instead of > > > > > Field(,default=request.now) > > > > > I will add a comment about this in the book. > > > > > Massimo > > > > > On Aug 3, 3:22 am, Armin Ronacher wrote: > > > > >> Hi, > > > > >>> True. but I would not call it a race condition. We timestamp > > > >>> everything with the time when a request arrives, not when it is > > > >>> processed, unless specified otherwise (datetime.now() instead of > > > >>> request.now) > > > > >> True. But that does not make it a better idea. Also, datetime.now() > > > >> should be consistently replaced with datetime.utcnow() because using > > > >> anythign else than UTC data internally is problematic for various > > > >> reasons. See the discussion on that topic in various i18n/l10n > > > >> libraries such as babel / pytz. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27995] Re: How to set http "keep-alive" parameter?
On Aug 5, 1:10 am, 陶艺夫 wrote: > You mean then the bug's gone in the newest version of CP? Hopefully > Can really CherryPy be used in a production environment? I'm a little > confused now. Works for me - either with Apache/WSGI or natively ona single-user Win32 client. F --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27994] Re: How to set http "keep-alive" parameter?
You mean then the bug's gone in the newest version of CP? Can really CherryPy be used in a production environment? I'm a little confused now. 2009/8/5 Fran > > On Aug 4, 10:17 pm, mdipierro wrote: > > Can you give it a try? If it works I will test it too. > > I've never seen the error, so can't test to see if the error goes > away. > > I have replaced wsgiserver.py with CP's wsgiserver\__init__.py > So far this is running fine on both my Windows PC & a Linux server > running Apache/WSGI. > Am not sure what I specifically need to test... > > F > > > On Aug 4, 3:22 pm, Fran wrote: > > > On Aug 4, 1:42 pm, mdipierro wrote: > > > > The cherrypy server has a timeout issue under some condition. > > > I wonder if this changeset improves things? > http://cherrypy.org/changeset/2483 > > > F > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27993] Re: Hacking the Windows version of web2py.py
Aha -- I think I need to tweak widget.pyc as well (to add the menu of IP addresses), but knowing that all this stuff is in library.zip was the piece I was missing. I assume I can just compile the corresponding ?.py (from the like- versioned source) and replace the corresponding element(s) of library. Thanks, scott On Aug 4, 5:34 pm, mdipierro wrote: > I do not know what changes you need to make but you can change the > main.pyc in library.zip. > > > > > In the source & Mac-standalone versions of web2py, one can (and I > > did :)) change/replace the file web2py.py in order to modify the > > server application. (In my case, I'm adding a list of server IPs to > > choose from and spawning an extra process; the latter could presumably > > be done elsewhere, but it is tied to the server running, so this way I > > can easily start/stop it when the server starts/stops.) > > > But in the Windows-standalone version, this file is not present > > (presumably because it's functionality is baked into web2py.exe). > > > So is there some way to make such modifications to the Windows- > > standalone version? Maybe some kind of hook(s) into web2py.exe? I'd > > even be willing to make a modified version of web2py.exe, but I don't > > see the source for it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27992] Re: Fwd: My thoughts on web2py
Hmmm. My bigger question is, are you still looking for assistance or do you have the book wrapped up? On Aug 4, 7:42 am, mdipierro wrote: > Almost done. 1-2 weeks. > > On Aug 4, 5:32 am, Pynthon wrote: > > > Nice, Massimo will there be a new book? > > > On 4 aug, 09:04, mdipierro wrote: > > > > Changing now into utcnow would break backward compatibility. > > > > I do agree with you that othen people may want to use > > > > Field(,default=datetime.utcnow()) > > > > instead of > > > > Field(,default=request.now) > > > > I will add a comment about this in the book. > > > > Massimo > > > > On Aug 3, 3:22 am, Armin Ronacher wrote: > > > > > Hi, > > > > > > True. but I would not call it a race condition. We timestamp > > > > > everything with the time when a request arrives, not when it is > > > > > processed, unless specified otherwise (datetime.now() instead of > > > > > request.now) > > > > > True. But that does not make it a better idea. Also, datetime.now() > > > > should be consistently replaced with datetime.utcnow() because using > > > > anythign else than UTC data internally is problematic for various > > > > reasons. See the discussion on that topic in various i18n/l10n > > > > libraries such as babel / pytz. > > > > > > True but I believe we never do that in web2py. It is also true that > > > > > nothing prevent the user from doing it but the same would be true with > > > > > other frameworks. > > > > > You're not doing it, a user might be doing that by accident or because > > > > he things it should work. This problem does not exist in other > > > > frameworks because besides web2py I don't know a single one that does > > > > this sort of execfile() + namespace thing or uses any other kind of > > > > throwaway modules. As soon as a single reference leaks from the > > > > execfile()'d namespace you're in big troubles and due to the open > > > > nature of Python this could happen very, very fast. > > > > > > Yes but because all relevant application code is executed within a > > > > > context and there are no references outside the context to stuff > > > > > inside the context, when a request is completed, the context is > > > > > deleted and everything should be garbage collected. > > > > > That depends on two things. First not having a reference leaked, > > > > which could happen with abstract base classes and other stuff that > > > > uses registries or steals non-weak references. Also and more > > > > importantly, the file descriptor limit is very low and the majority of > > > > Python implementations will only collect that on the GC run (always, > > > > no matter where references are). Say you're opening three files per > > > > request and you have more than 100 requests/sec you could lose all > > > > file descriptors that are available before the GC even thought about > > > > running. > > > > > Regards, > > > > Armin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27991] Re: How to set http "keep-alive" parameter?
On Aug 4, 10:17 pm, mdipierro wrote: > Can you give it a try? If it works I will test it too. I've never seen the error, so can't test to see if the error goes away. I have replaced wsgiserver.py with CP's wsgiserver\__init__.py So far this is running fine on both my Windows PC & a Linux server running Apache/WSGI. Am not sure what I specifically need to test... F > On Aug 4, 3:22 pm, Fran wrote: > > On Aug 4, 1:42 pm, mdipierro wrote: > > > The cherrypy server has a timeout issue under some condition. > > I wonder if this changeset improves > > things?http://cherrypy.org/changeset/2483 > > F --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27990] Re: Default CRYPT() is unsecure
On Aug 4, 2009, at 2:06 PM, mdipierro wrote:
>
> I think the simples solution coule be:
> - add fixed 0.5 second delay to any login
I like that.
> - add two optional fields to db.auth_user that locks an account for 15
> minutes after 3 failed logins.
> Field('last_login')
> Field('failed_logins')
How about just making the delay: 0.5 + max(failed_logins, 10) seconds?
A brute-force attack is going to require many, many attempts, so is
there really a need to lock the account for more than a few seconds? A
10-second delay will throttle the attack to 360/hour per attacking
machine, which will make a brute-force attack impractical unless the
attacker is incredibly lucky, or the victim has an incredibly bad
password.
An it won't be necessary to give any feedback to the user (though we
could do a flash, I suppose), since worst case it'll just be a rather
slow (10-second or whatever) response to the login attempt.
It'd be useful to log something for the admin if failed_logins exceeds
some threshold.
>
> Massimo
>
> On Aug 4, 9:56 am, Jonathan Lundell wrote:
>> On Aug 4, 2009, at 6:01 AM, mdipierro wrote:
>>
>>
>>
>>> One issue is how to implement this if we use the
>>> request.env.remote_addr then it does not work behind a proxy, if we
>>> use request.env.http_x_if_forwarded_for, it works only on apache and
>>> it can spoofed anyway.
>>
>> I don't think we should be looking at the remote IP anyway.
>>
>> The problem is that these days a brute force attack can (fairly)
>> easily be distributed across a lot of zombie machines.
>>
>> If we just have a timer, and don't actually disable the account, then
>> the burden on the real user won't be that high, and then only if she
>> tries to log in while the attack is going on.
>>
>> A minor advantage to using only the account name is that all we need
>> to implement it is another field or two in the user table.
>>
>>
>>
>>> Ideas?
>>
>>> Massimo
>>
>>> On Aug 4, 7:50 am, Pynthon wrote:
Ah, nevermind then...
>>
On 4 aug, 14:47, mdipierro wrote:
>>
> This can be added easily and it does not affect backward
> compatibility.
>>
> Massimo
>>
> On Aug 4, 7:37 am, Rob Scheibel wrote:
>>
>> Very good points in this discussion. I would like to see the
>> addition
>> of a processing delay added for numerous failed login attempts.
>> This
>> is what the larger sites are doing now - it slows down the
>> dictionary
>> attacks by adding 1/2 a second to each successive bad login
>> attempt
>> until you hit some max (i.e. 20 seconds) and then it resets (note
>> that
>> it should be based on Host IP but also user account in case
>> attacks
>> are coming from multiple IPs). Using this method it will take a
>> LONG
>> time to crack a relatively strong pass and most people give up
>> and go
>> elsewhere. It's also nice because it isn't too much of a nuicance
>> to a
>> user (they might be annoyed by a 20 second login delay, but they
>> can
>> still get in vs being locked out).
>>
>> It's also pretty easy to implement. You add a table to track the
>> "bad
>> IPs" and count/clear them based on timestamps. Then you add a
>> field to
>> the users table to track successive failed login attempts on that
>> account and clear it on each login.
>>
>> You could also always do like LiNode is doing and lock an account
>> by
>> resetting the pass to a random value after x bad logins and
>> emailing
>> the new pass to the user.
>>
>> just flat-out locking out users for a period of time can be used
>> to a
>> person's advantage. Say you knew "bob" had an account on a
>> system, but
>> you didn't want him to be able to access it. Then you'd just
>> try a
>> bunch of bad passwords using his login and he'd be locked out...
>>
>> Just my $0.02.
>>
>> Thanks for the all the great work on web2py - it's been a treat
>> to
>> work with!
>>
>> -rob
>>
>> On Aug 2, 6:57 pm, Jonathan Lundell wrote:
>>
>>> On Aug 2, 2009, at 3:10 PM, Jonathan Lundell wrote:
>>
On Aug 1, 2009, at 9:48 AM, mdipierro wrote:
>>
> Mind that none of this has anything to do with the ability
> of an
> attacker to guess the passwords to access a web2py site.
> This is
> about
> protecting the users form the administrators who may decrypt
> their
> hashed passords and access the users's account using their
> decrypted
> passwords (of an attacker who is already in the system and can
> act as
> the web2py administrator). But mind that the administrator
> does not
> even need to decrypt passwords to access them. He just log
> request.vars.password from the model file to get the login
> passwords
> before they are encrypted. This is true in web2py and in
[web2py:27989] Re: Hacking the Windows version of web2py.py
I do not know what changes you need to make but you can change the main.pyc in library.zip. > In the source & Mac-standalone versions of web2py, one can (and I > did :)) change/replace the file web2py.py in order to modify the > server application. (In my case, I'm adding a list of server IPs to > choose from and spawning an extra process; the latter could presumably > be done elsewhere, but it is tied to the server running, so this way I > can easily start/stop it when the server starts/stops.) > > But in the Windows-standalone version, this file is not present > (presumably because it's functionality is baked into web2py.exe). > > So is there some way to make such modifications to the Windows- > standalone version? Maybe some kind of hook(s) into web2py.exe? I'd > even be willing to make a modified version of web2py.exe, but I don't > see the source for it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27988] Re: r1045 breaks some upload fields
On Aug 4, 2009, at 2:16 PM, mdipierro wrote:
>
> I believe this problem was fixed in 1.65.10. Am I wrong?
I don't have a test case; I've just been reading the source. But I
suspect that it's not fixed. Consider the flow when f is a
FieldStorage object with list = None:
> elif field.type == 'upload':
> f = self.vars[fieldname]
> fd = fieldname + '__delete'
> if f == '':
> if self.vars.get(fd, False) or not self.record:
> fields[fieldname] = ''
> else:
> fields[fieldname] = self.record[fieldname]
> continue
> elif not f:
> continue # not sure this ever happens but safety
> check
> elif not isinstance(f, (str, unicode)):
> (source_file, original_filename) = (f.file,
> f.filename)
We'll still execute the "not f" test, right? And it'll still throw the
exception, at least in Python 2.5.
And in 2.6, you won't get to the next elif. Is that bad? I'm still
confused about what the code is actually trying to accomplish, so I
don't know. What *should* be happening in the case that Jose and Fran
are having problems with?
>
> Massimo
>
> On Aug 4, 3:23 pm, Jonathan Lundell wrote:
>> On Aug 4, 2009, at 9:38 AM, Jonathan Lundell wrote:
>>
>>
>>
>>
>>
>>> On Aug 3, 2009, at 8:33 AM, Jose wrote:
>>
I have just tried this in Windows XP(r1153) + python 2.5.x
>>
db.define_table('unatabla',
Field('nombre'),
Field('imagen', 'upload'),
)
>>
The following mistake takes is produced when I do submit:
>>
Error traceback
Traceback (most recent call last):
File "E:\web2py2\gluon\restricted.py", line 178, in restricted
exec ccode in environment
File "E:/web2py2/applications/prueba/controllers/appadmin.py", line
255, in
File "E:\web2py2\gluon\globals.py", line 101, in
self._caller = lambda f: f()
File "E:/web2py2/applications/prueba/controllers/appadmin.py", line
104, in insert
if form.accepts(request.vars, session):
File "E:\web2py2\gluon\sqlhtml.py", line 809, in accepts
if not f:
File "E:\Python25\lib\cgi.py", line 633, in __len__
return len(self.keys())
File "E:\Python25\lib\cgi.py", line 609, in keys
raise TypeError, "not indexable"
TypeError: not indexable
>>
>>> I took a quick look at the code behind this trace, and I can offer a
>>> small clue. I don't know enough about what's going on to offer a
>>> solution, but perhaps it'll ring a bell for someone who understands
>>> the code better than I do.
>>
>>> Here's the code in the tree:
>>
elif field.type == 'upload':
f = self.vars[fieldname]
fd = fieldname + '__delete'
if not f:
>>
>>> This used to be f == ''.
>>
if self.vars.get(fd, False) or not self.record:
fields[fieldname] = ''
else:
fields[fieldname] = self.record[fieldname]
continue
elif not isinstance(f, (str, unicode)):
(source_file, original_filename) = (f.file,
f.filename)
else:
### do not know why this happens, it should not
>>
>>> This comment bothers me, and I wonder if it might be related.
>>
(source_file, original_filename) = \
(cStringIO.StringIO(f), 'file.txt')
logging.warn('here')
fields[fieldname] = field.store(source_file,
original_filename)
logging.warn('there')
if field.uploadfield and not
field.uploadfield==True:
fields[field.uploadfield] = source_file.read()
continue
>>
>>> In the failing case, f appears to be an instance of FieldStorage,
>>> from
>>> cgi.py. It appears that Python implements "if not f" as "if not
>>> len(f)". FieldStorage defines __len__ as "len(self.keys()), and
>>> that's
>>> where we run into trouble.
>>
>>> def keys(self):
>>> """Dictionary style keys() method."""
>>> if self.list is None:
>>> raise TypeError, "not indexable"
>>> keys = []
>>> for item in self.list:
>>> if item.name not in keys: keys.append(item.name)
>>> return keys
>>
>>> And self.list is None unless one of two things happens:
>>
>>> if ctype == 'application/x-www-form-urlencoded':
>>> self.read_urlencoded()
>>> elif ctype[:10] == 'multipart/':
>>> self.read_multi(environ, keep_blank_values,
>>> strict_parsing)
>>> else:
>>> self.read_single()
>>
>>> Only the first two calls (read_urlencoded() and read_multi()) set
>
[web2py:27987] Re: Ticket 127.0.0.1.2009- error
Could you try replace your download function with def download(): return response.download(request,db) On Aug 4, 3:42 pm, jayvandal wrote: > Hi. > I am trying the "Images" in the manual and I am on page 61 . > I tried to select all and copy the error info. Is there a better way > to copy the error info? > Thanks > > Error ticket for "images" > Ticket 127.0.0.1.2009-08-04.14-35-15.67e6ba82-76c8-4172-8868- > dfc459e24fd2 > > Error traceback > 1.2.3.4.5.6.7.8.9. Traceback (most recent call last): File "gluon/ > restricted.py", line 178, in restricted File "C:/web2py_win(2)/web2py/ > applications/images/controllers/default.py", line 19, in > File "gluon/globals.py", line 101, in File "C:/web2py_win(2)/ > web2py/applications/images/controllers/default.py", line 9, in show > File "gluon/sqlhtml.py", line 743, in accepts File "gluon/html.py", > line 1135, in acceptsTypeError: 'NoneType' object is not iterable > > In file: C:\web2py_win(2)\web2py\applications\images/controllers/ > default.py > 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20. def index(): > images=db().select(db.image.ALL,orderby=db.image.title) return dict > (images=images) def show(): image=db(db.image.id==request.args > [0]).select()[0] form=SQLFORM(db.comment,fields= > ['author','email','body']) form.vars.image_id=image.id if > form.accepts(request.vars.session): response.flash='your comment > is posted' comments=db(db.comment.image_id==image.id).select() > return dict(image=image,comments=comments,form=form) def download > (): import os path=os.path.join(request.folder,'uploads',request.args > [0]) return response.stream(path)response._vars=response._caller > (show) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27986] Re: How to set http "keep-alive" parameter?
Can you give it a try? If it works I will test it too. On Aug 4, 3:22 pm, Fran wrote: > On Aug 4, 1:42 pm, mdipierro wrote: > > > The cherrypy server has a timeout issue under some condition. > > I wonder if this changeset improves things?http://cherrypy.org/changeset/2483 > > F --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27985] Re: r1045 breaks some upload fields
I believe this problem was fixed in 1.65.10. Am I wrong?
Massimo
On Aug 4, 3:23 pm, Jonathan Lundell wrote:
> On Aug 4, 2009, at 9:38 AM, Jonathan Lundell wrote:
>
>
>
>
>
> > On Aug 3, 2009, at 8:33 AM, Jose wrote:
>
> >> I have just tried this in Windows XP(r1153) + python 2.5.x
>
> >> db.define_table('unatabla',
> >> Field('nombre'),
> >> Field('imagen', 'upload'),
> >> )
>
> >> The following mistake takes is produced when I do submit:
>
> >> Error traceback
> >> Traceback (most recent call last):
> >> File "E:\web2py2\gluon\restricted.py", line 178, in restricted
> >> exec ccode in environment
> >> File "E:/web2py2/applications/prueba/controllers/appadmin.py", line
> >> 255, in
> >> File "E:\web2py2\gluon\globals.py", line 101, in
> >> self._caller = lambda f: f()
> >> File "E:/web2py2/applications/prueba/controllers/appadmin.py", line
> >> 104, in insert
> >> if form.accepts(request.vars, session):
> >> File "E:\web2py2\gluon\sqlhtml.py", line 809, in accepts
> >> if not f:
> >> File "E:\Python25\lib\cgi.py", line 633, in __len__
> >> return len(self.keys())
> >> File "E:\Python25\lib\cgi.py", line 609, in keys
> >> raise TypeError, "not indexable"
> >> TypeError: not indexable
>
> > I took a quick look at the code behind this trace, and I can offer a
> > small clue. I don't know enough about what's going on to offer a
> > solution, but perhaps it'll ring a bell for someone who understands
> > the code better than I do.
>
> > Here's the code in the tree:
>
> >> elif field.type == 'upload':
> >> f = self.vars[fieldname]
> >> fd = fieldname + '__delete'
> >> if not f:
>
> > This used to be f == ''.
>
> >> if self.vars.get(fd, False) or not self.record:
> >> fields[fieldname] = ''
> >> else:
> >> fields[fieldname] = self.record[fieldname]
> >> continue
> >> elif not isinstance(f, (str, unicode)):
> >> (source_file, original_filename) = (f.file,
> >> f.filename)
> >> else:
> >> ### do not know why this happens, it should not
>
> > This comment bothers me, and I wonder if it might be related.
>
> >> (source_file, original_filename) = \
> >> (cStringIO.StringIO(f), 'file.txt')
> >> logging.warn('here')
> >> fields[fieldname] = field.store(source_file,
> >> original_filename)
> >> logging.warn('there')
> >> if field.uploadfield and not field.uploadfield==True:
> >> fields[field.uploadfield] = source_file.read()
> >> continue
>
> > In the failing case, f appears to be an instance of FieldStorage, from
> > cgi.py. It appears that Python implements "if not f" as "if not
> > len(f)". FieldStorage defines __len__ as "len(self.keys()), and that's
> > where we run into trouble.
>
> > def keys(self):
> > """Dictionary style keys() method."""
> > if self.list is None:
> > raise TypeError, "not indexable"
> > keys = []
> > for item in self.list:
> > if item.name not in keys: keys.append(item.name)
> > return keys
>
> > And self.list is None unless one of two things happens:
>
> > if ctype == 'application/x-www-form-urlencoded':
> > self.read_urlencoded()
> > elif ctype[:10] == 'multipart/':
> > self.read_multi(environ, keep_blank_values,
> > strict_parsing)
> > else:
> > self.read_single()
>
> > Only the first two calls (read_urlencoded() and read_multi()) set
> > self.list to a list. Otherwise it's None, and our 'if not f' will be
> > sent an exception.
>
> > If this case is expected, or at should be a detectable error
> > condition, then perhaps we should catch the exception and treat it as
> > a case of 'not f'. Or something. But as I say, I don't really know
> > enough about the intent of this code to go any farther.
>
> I see that in 2.6, FieldStorage has a __nonzero__() method that does
> the right thing (and will be used in preference to __len__).
>
> So part of the problem you guys are seeing might be the difference in
> how 2.6 (vs 2.5) handles "if not f".
>
> Anyway, I don't see how the sqlhtml upload logic deals with f being a
> FieldStorage object.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27984] Re: Fwd: My thoughts on web2py
This is a good point but I disagree and agree. I disagree because I do not think we ever wrote messy code because we needed to keep backward compatibility. So far we never had to compromise much. Moreover backward compatibility is a strength of web2py. I agree because one day all existing database divers will be ported to Python 3.0 and GAE will support python 3.0. When this happen (in 2-3 years) we may want to release a backward incompatible version of web2py (while keeping support for the old one). That would be the time to change a few other things and that will be the time to discuss what to change. Massimo On Aug 4, 12:55 pm, Alex Fanjul wrote: > Massimo, > Many times I have seen that, due to backward compatibility, we are > forcing to write "messy" code in web2py applitacations. > Evenmore some issues will never fix in the right way bacause of that... > Won't you consider/planning to do a breakpoint with a major version > web2py 2.0? and solve such things? > > Python did it with 3.0, isn't it? > > Only out of curiosity, sorry if it's reduplicate question, regards, > Alex F > > El 04/08/2009 9:04, mdipierro escribió: > > > > > Changing now into utcnow would break backward compatibility. > > > I do agree with you that othen people may want to use > > > Field(,default=datetime.utcnow()) > > > instead of > > > Field(,default=request.now) > > > I will add a comment about this in the book. > > > Massimo > > > On Aug 3, 3:22 am, Armin Ronacher wrote: > > >> Hi, > > >>> True. but I would not call it a race condition. We timestamp > >>> everything with the time when a request arrives, not when it is > >>> processed, unless specified otherwise (datetime.now() instead of > >>> request.now) > > >> True. But that does not make it a better idea. Also, datetime.now() > >> should be consistently replaced with datetime.utcnow() because using > >> anythign else than UTC data internally is problematic for various > >> reasons. See the discussion on that topic in various i18n/l10n > >> libraries such as babel / pytz. > > >>> True but I believe we never do that in web2py. It is also true that > >>> nothing prevent the user from doing it but the same would be true with > >>> other frameworks. > > >> You're not doing it, a user might be doing that by accident or because > >> he things it should work. This problem does not exist in other > >> frameworks because besides web2py I don't know a single one that does > >> this sort of execfile() + namespace thing or uses any other kind of > >> throwaway modules. As soon as a single reference leaks from the > >> execfile()'d namespace you're in big troubles and due to the open > >> nature of Python this could happen very, very fast. > > >>> Yes but because all relevant application code is executed within a > >>> context and there are no references outside the context to stuff > >>> inside the context, when a request is completed, the context is > >>> deleted and everything should be garbage collected. > > >> That depends on two things. First not having a reference leaked, > >> which could happen with abstract base classes and other stuff that > >> uses registries or steals non-weak references. Also and more > >> importantly, the file descriptor limit is very low and the majority of > >> Python implementations will only collect that on the GC run (always, > >> no matter where references are). Say you're opening three files per > >> request and you have more than 100 requests/sec you could lose all > >> file descriptors that are available before the GC even thought about > >> running. > > >> Regards, > >> Armin > > -- > Alejandro Fanjul Fdez. > alex.fan...@gmail.comwww.mhproject.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27983] Hacking the Windows version of web2py.py
In the source & Mac-standalone versions of web2py, one can (and I did :)) change/replace the file web2py.py in order to modify the server application. (In my case, I'm adding a list of server IPs to choose from and spawning an extra process; the latter could presumably be done elsewhere, but it is tied to the server running, so this way I can easily start/stop it when the server starts/stops.) But in the Windows-standalone version, this file is not present (presumably because it's functionality is baked into web2py.exe). So is there some way to make such modifications to the Windows- standalone version? Maybe some kind of hook(s) into web2py.exe? I'd even be willing to make a modified version of web2py.exe, but I don't see the source for it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27982] Re: Fwd: My thoughts on web2py
+1 Really bad idea. I have never seen even a shadow of reason for this. We trust Massimo with his declaration. Please, try to understand. This is about serious production environments, important applications and making money using web2py. We could consider it if there was a real need. But there is none. On Aug 4, 2009 9:00 PM, "Fran" wrote: On Aug 4, 7:30 pm, Pynthon wrote: > Yeah maybe a complete web2py 2 rewrite. W... I believe this is a bad idea as we really don't want to break existing apps - this is a *key* strength of web2py & one many of it's adherents really value. This is what justifies the term 'Enterprise'. Many of the 'issues' are easy to solve without doing so & the rest are pretty much design decisions. They are seen as key strengths for some & key weaknesses for others. Let those who see them as strengths enjoy this & if others cannot live with what they see as weaknesses, let them choose from the many other frameworks out there. F --~--~-~--~~~---~--~~ You received this message because you are s... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27981] Re: Fwd: My thoughts on web2py
I don't feel it is necessary to re-write anything yet. There is a lot of good in it as it is. Don't just give up on it when you run into a few difficulties. We are not talking about anything that won't be addressed either. It is more of an issue of how it is addressed, and for all the "weaknesses" in this framework, there are a hell of a lot more strengths. Have patience, and don't forget this is a VERY young project. Also, you may not agree with all the decisions all the time, but then no one will in any framework. You can't please all the people all the time. The key is to remember what brought you to this framework, and if that still stands. All software has weaknesses, the question is whether it is being dealt with or monitored. If it is, then one day in the near future it will be addressed, but don't confuse speed of resolving all problems brought up with quality solutions. Often the best solution will require a lot of dialogue and a lot of analysis before implementing. Also, not breaking backwards compatibility is a great rule to prevent software from moving too fast. If the software breaks backwards compatibility with every minor release, no one will use it because it is not serious. If it breaks with every major release, no serious project will use it because it would be too expensive to maintain. Therefore, if all I have to do is use some added code in order to solve the problem but preserve backward compatibility, then I am all for it. If you have a small project that you can re-write in a day, you won't care, but then I would not care about these minor issues if that is all I needed it for. I am still following this framework because I believe I can build something serious with it, not just a 5 minute wiki AND I know I won't have to re-write everything once a year. Breaking backwards compatibility is a very serious decision, and I am very happy Massimo takes it VERY seriously. This attitude is what will set this framework apart, and will make it deserve the title of "Enterprise Framework". Otherwise, it is just another framework. If this project has to break backwards compatibility though, I would hope it is done at the same time that it transitions to Python 3, as that would take care of everything all at once. However, there is a LOT of work to be done in assembling a list of issues and solutions before that happens. So just be patient, and continue to use the framework, that is how more issues can be discovered, and solutions proposed. However, for today, there is no reason for even talking about breaking backwards compatibility. On Aug 4, 12:00 pm, Fran wrote: > On Aug 4, 7:30 pm, Pynthon wrote: > > > Yeah maybe a complete web2py 2 rewrite. With nice and better coding... > > I believe this is a bad idea as we really don't want to break existing > apps - this is a *key* strength of web2py & one many of it's adherents > really value. This is what justifies the term 'Enterprise'. > > Many of the 'issues' are easy to solve without doing so & the rest are > pretty much design decisions. > They are seen as key strengths for some & key weaknesses for others. > Let those who see them as strengths enjoy this & if others cannot live > with what they see as weaknesses, let them choose from the many other > frameworks out there. > > F --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27980] Re: Ticket 127.0.0.1.2009-08-04.11-42-18.1144ad5e-5ded-48ca-8871-99bb6695e5c8
The content is is applications/[yourapp]/errors/ 127.0.0.1.2009-08-04.11-42-18.1144ad5e-5ded-48ca-8871-99bb6695e5c8 On Aug 4, 1:57 pm, Fran wrote: > On Aug 4, 6:50 pm, jayvandal wrote: > > > I have an error in the IMAGES in your book. I am on page 60. > > this is the > > Ticket > > 127.0.0.1.2009-08-04.11-42-18.1144ad5e-5ded-48ca-8871-99bb6695e5c8 > > You need to provide the ticket contents, not the link to the ticket... > > F --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27979] Re: Default CRYPT() is unsecure
I think the simples solution coule be:
- add fixed 0.5 second delay to any login
- add two optional fields to db.auth_user that locks an account for 15
minutes after 3 failed logins.
Field('last_login')
Field('failed_logins')
Massimo
On Aug 4, 9:56 am, Jonathan Lundell wrote:
> On Aug 4, 2009, at 6:01 AM, mdipierro wrote:
>
>
>
> > One issue is how to implement this if we use the
> > request.env.remote_addr then it does not work behind a proxy, if we
> > use request.env.http_x_if_forwarded_for, it works only on apache and
> > it can spoofed anyway.
>
> I don't think we should be looking at the remote IP anyway.
>
> The problem is that these days a brute force attack can (fairly)
> easily be distributed across a lot of zombie machines.
>
> If we just have a timer, and don't actually disable the account, then
> the burden on the real user won't be that high, and then only if she
> tries to log in while the attack is going on.
>
> A minor advantage to using only the account name is that all we need
> to implement it is another field or two in the user table.
>
>
>
> > Ideas?
>
> > Massimo
>
> > On Aug 4, 7:50 am, Pynthon wrote:
> >> Ah, nevermind then...
>
> >> On 4 aug, 14:47, mdipierro wrote:
>
> >>> This can be added easily and it does not affect backward
> >>> compatibility.
>
> >>> Massimo
>
> >>> On Aug 4, 7:37 am, Rob Scheibel wrote:
>
> Very good points in this discussion. I would like to see the
> addition
> of a processing delay added for numerous failed login attempts.
> This
> is what the larger sites are doing now - it slows down the
> dictionary
> attacks by adding 1/2 a second to each successive bad login attempt
> until you hit some max (i.e. 20 seconds) and then it resets (note
> that
> it should be based on Host IP but also user account in case attacks
> are coming from multiple IPs). Using this method it will take a
> LONG
> time to crack a relatively strong pass and most people give up
> and go
> elsewhere. It's also nice because it isn't too much of a nuicance
> to a
> user (they might be annoyed by a 20 second login delay, but they
> can
> still get in vs being locked out).
>
> It's also pretty easy to implement. You add a table to track the
> "bad
> IPs" and count/clear them based on timestamps. Then you add a
> field to
> the users table to track successive failed login attempts on that
> account and clear it on each login.
>
> You could also always do like LiNode is doing and lock an account
> by
> resetting the pass to a random value after x bad logins and
> emailing
> the new pass to the user.
>
> just flat-out locking out users for a period of time can be used
> to a
> person's advantage. Say you knew "bob" had an account on a
> system, but
> you didn't want him to be able to access it. Then you'd just try a
> bunch of bad passwords using his login and he'd be locked out...
>
> Just my $0.02.
>
> Thanks for the all the great work on web2py - it's been a treat to
> work with!
>
> -rob
>
> On Aug 2, 6:57 pm, Jonathan Lundell wrote:
>
> > On Aug 2, 2009, at 3:10 PM, Jonathan Lundell wrote:
>
> >> On Aug 1, 2009, at 9:48 AM, mdipierro wrote:
>
> >>> Mind that none of this has anything to do with the ability of an
> >>> attacker to guess the passwords to access a web2py site. This is
> >>> about
> >>> protecting the users form the administrators who may decrypt
> >>> their
> >>> hashed passords and access the users's account using their
> >>> decrypted
> >>> passwords (of an attacker who is already in the system and can
> >>> act as
> >>> the web2py administrator). But mind that the administrator
> >>> does not
> >>> even need to decrypt passwords to access them. He just log
> >>> request.vars.password from the model file to get the login
> >>> passwords
> >>> before they are encrypted. This is true in web2py and in any
> >>> other
> >>> web
> >>> based system.
>
> >>> I am much more concerned about a different issue: when an
> >>> attacker
> >>> wants to enter a site and repeatedly guesses the password.
> >>> Perhaps there should be an option in auth that locks accounts
> >>> after
> >>> many failed logins. We could have another system table to handle
> >>> that.
>
> >> How about a default STRONG as well as HMAC? If a developer
> >> wants to
> >> allow weaker passwords, let the burden be in that direction.
>
> >> An account-locking policy is a good idea. If the table has a
> >> timestamp, the lock can be temporary, at least initially. Lock
> >> the
> >> account for a n seconds after n failures. Or something like that.
>
> > One reason for a delay that simply imposes rate-limiting
[web2py:27978] Ticket 127.0.0.1.2009- error
Hi. I am trying the "Images" in the manual and I am on page 61 . I tried to select all and copy the error info. Is there a better way to copy the error info? Thanks Error ticket for "images" Ticket 127.0.0.1.2009-08-04.14-35-15.67e6ba82-76c8-4172-8868- dfc459e24fd2 Error traceback 1.2.3.4.5.6.7.8.9. Traceback (most recent call last): File "gluon/ restricted.py", line 178, in restricted File "C:/web2py_win(2)/web2py/ applications/images/controllers/default.py", line 19, in File "gluon/globals.py", line 101, in File "C:/web2py_win(2)/ web2py/applications/images/controllers/default.py", line 9, in show File "gluon/sqlhtml.py", line 743, in accepts File "gluon/html.py", line 1135, in acceptsTypeError: 'NoneType' object is not iterable In file: C:\web2py_win(2)\web2py\applications\images/controllers/ default.py 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20. def index(): images=db().select(db.image.ALL,orderby=db.image.title) return dict (images=images) def show(): image=db(db.image.id==request.args [0]).select()[0] form=SQLFORM(db.comment,fields= ['author','email','body']) form.vars.image_id=image.id if form.accepts(request.vars.session): response.flash='your comment is posted' comments=db(db.comment.image_id==image.id).select() return dict(image=image,comments=comments,form=form) def download (): import os path=os.path.join(request.folder,'uploads',request.args [0]) return response.stream(path)response._vars=response._caller (show) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27977] Re: How to set http "keep-alive" parameter?
On Aug 4, 2009, at 1:08 PM, Yarko Tymciurak wrote: > On Tue, Aug 4, 2009 at 9:49 AM, Jonathan Lundell > wrote: > > On Aug 4, 2009, at 5:42 AM, mdipierro wrote: > > > The cherrypy server has a simsout issue under some condition. It > > always worked great for me (I tried 1GB successfully) It seems to > > depend on the client. What browser are you using? Can you try a > > different one. > > If this is the same server that's serving up the web2py downloads, > then we've seen several reports with different browsers. I've seen > silently truncated downloads with both Safari and Firefox. > > AND it seems to be tied to interaction with a particular file, e.g. > one very large file will work; the next one will not (and then the > one that does not, does so consistently)... My recollection is that it's inconsistent to the extent that the partial download is not always the same length. But that could bear confirmation. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27976] Re: r1045 breaks some upload fields
On Aug 4, 2009, at 9:38 AM, Jonathan Lundell wrote:
>
> On Aug 3, 2009, at 8:33 AM, Jose wrote:
>
>> I have just tried this in Windows XP(r1153) + python 2.5.x
>>
>> db.define_table('unatabla',
>> Field('nombre'),
>> Field('imagen', 'upload'),
>> )
>>
>> The following mistake takes is produced when I do submit:
>>
>> Error traceback
>> Traceback (most recent call last):
>> File "E:\web2py2\gluon\restricted.py", line 178, in restricted
>> exec ccode in environment
>> File "E:/web2py2/applications/prueba/controllers/appadmin.py", line
>> 255, in
>> File "E:\web2py2\gluon\globals.py", line 101, in
>> self._caller = lambda f: f()
>> File "E:/web2py2/applications/prueba/controllers/appadmin.py", line
>> 104, in insert
>> if form.accepts(request.vars, session):
>> File "E:\web2py2\gluon\sqlhtml.py", line 809, in accepts
>> if not f:
>> File "E:\Python25\lib\cgi.py", line 633, in __len__
>> return len(self.keys())
>> File "E:\Python25\lib\cgi.py", line 609, in keys
>> raise TypeError, "not indexable"
>> TypeError: not indexable
>
> I took a quick look at the code behind this trace, and I can offer a
> small clue. I don't know enough about what's going on to offer a
> solution, but perhaps it'll ring a bell for someone who understands
> the code better than I do.
>
> Here's the code in the tree:
>
>>elif field.type == 'upload':
>>f = self.vars[fieldname]
>>fd = fieldname + '__delete'
>>if not f:
>
> This used to be f == ''.
>
>>if self.vars.get(fd, False) or not self.record:
>>fields[fieldname] = ''
>>else:
>>fields[fieldname] = self.record[fieldname]
>>continue
>>elif not isinstance(f, (str, unicode)):
>>(source_file, original_filename) = (f.file,
>> f.filename)
>>else:
>>### do not know why this happens, it should not
>
> This comment bothers me, and I wonder if it might be related.
>
>>(source_file, original_filename) = \
>>(cStringIO.StringIO(f), 'file.txt')
>>logging.warn('here')
>>fields[fieldname] = field.store(source_file,
>> original_filename)
>>logging.warn('there')
>>if field.uploadfield and not field.uploadfield==True:
>>fields[field.uploadfield] = source_file.read()
>>continue
>>
>
> In the failing case, f appears to be an instance of FieldStorage, from
> cgi.py. It appears that Python implements "if not f" as "if not
> len(f)". FieldStorage defines __len__ as "len(self.keys()), and that's
> where we run into trouble.
>
> def keys(self):
> """Dictionary style keys() method."""
> if self.list is None:
> raise TypeError, "not indexable"
> keys = []
> for item in self.list:
> if item.name not in keys: keys.append(item.name)
> return keys
>
> And self.list is None unless one of two things happens:
>
> if ctype == 'application/x-www-form-urlencoded':
> self.read_urlencoded()
> elif ctype[:10] == 'multipart/':
> self.read_multi(environ, keep_blank_values,
> strict_parsing)
> else:
> self.read_single()
>
> Only the first two calls (read_urlencoded() and read_multi()) set
> self.list to a list. Otherwise it's None, and our 'if not f' will be
> sent an exception.
>
> If this case is expected, or at should be a detectable error
> condition, then perhaps we should catch the exception and treat it as
> a case of 'not f'. Or something. But as I say, I don't really know
> enough about the intent of this code to go any farther.
I see that in 2.6, FieldStorage has a __nonzero__() method that does
the right thing (and will be used in preference to __len__).
So part of the problem you guys are seeing might be the difference in
how 2.6 (vs 2.5) handles "if not f".
Anyway, I don't see how the sqlhtml upload logic deals with f being a
FieldStorage object.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27975] Re: How to set http "keep-alive" parameter?
On Aug 4, 1:42 pm, mdipierro wrote: > The cherrypy server has a timeout issue under some condition. I wonder if this changeset improves things? http://cherrypy.org/changeset/2483 F --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27974] Re: Authentication: login and registration
On Aug 4, 2:26 pm, Johann Spies wrote: > My next > question comes from the fact that now anyone on the ldap-tree can > login and then become a registered user. I guess you can't move those users that you wish to login to be placed in a specific OU so that the logins can be restricted to just that OU? > At the moment there are at least two problems: > 1. Anyone in the ldap-tree can login and will then be registered > although there is no email address and registration key. > I want only registered users to be able to log in. And I want the > registration to be approved by the administrator before it is valid. > How do I do it in this setup? > auth.settings.registration_requires_approval = True Unfortunately Auth isn't currently set-up the way that you want it to be. This setting is only activated during auth.register() which isn't happening when users login through LDAP. It also doesn't check whether there is an existing registration_key. I'd consider this a bug...a patch is simple & so I'll send to Massimo to see if he agrees that this should still be checked with alternate login methods. However this won't help you majorly since you'd have to block all AD users other than those you anted to be able to access. Options that I can see for changing Web2Py to work as you'd like it: (1) Have an option where ldap-auth checks for Group membership & only allows in users who are in that group (defaulting to None, so no group check done) ldap_auth(server='stbldap01.sun.ac.za', port=636, base_dn='ou=users,O=SU', mode='cn', secure=True, group='Permitted Users') (2) Have an option to auth.login to say that even alternate login types need to register 1st auth.settings.registration_required = True (default to False for backward compatibility & probable usually- desired method) I think both of these have generic value & would be worth enhancing the system with. (2) Seems to be what you're after & is easier to code, so I'll work on that 1st. I'm happy to take suggestions from anyone on the syntax of these settings :) > 2. Any email address I type in results in an error: "Invalid email address" > t.email.requires = [IS_EMAIL(), IS_NOT_IN_DB(db, db.auth_user.email)] > Why does the registration form complain about an invalid email address? This is during register(), right? I can't see why that would happen & I can't replicate it here... Not sure why you get "Invalid email address" as the default error for the IS_EMAIL() validator is: error_message='invalid email!' The default requires is: t.email.requires = [IS_EMAIL (error_message=self.messages.invalid_email), IS_NOT_IN_DB(db, db.auth_user.email)] with self.messages.invalid_email = 'Invalid email' These values haven't changed in a long time, so where this comes from I cannot tell... (If it's the IS_IN_DB validator then get a 'Vlue already in database' error...) F --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27973] Re: How to set http "keep-alive" parameter?
On Tue, Aug 4, 2009 at 9:49 AM, Jonathan Lundell wrote: > > On Aug 4, 2009, at 5:42 AM, mdipierro wrote: > > > The cherrypy server has a simsout issue under some condition. It > > always worked great for me (I tried 1GB successfully) It seems to > > depend on the client. What browser are you using? Can you try a > > different one. > > If this is the same server that's serving up the web2py downloads, > then we've seen several reports with different browsers. I've seen > silently truncated downloads with both Safari and Firefox. AND it seems to be tied to interaction with a particular file, e.g. one very large file will work; the next one will not (and then the one that does not, does so consistently)... > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27972] Re: Fwd: My thoughts on web2py
On Aug 4, 7:30 pm, Pynthon wrote: > Yeah maybe a complete web2py 2 rewrite. With nice and better coding... I believe this is a bad idea as we really don't want to break existing apps - this is a *key* strength of web2py & one many of it's adherents really value. This is what justifies the term 'Enterprise'. Many of the 'issues' are easy to solve without doing so & the rest are pretty much design decisions. They are seen as key strengths for some & key weaknesses for others. Let those who see them as strengths enjoy this & if others cannot live with what they see as weaknesses, let them choose from the many other frameworks out there. F --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27971] Re: Ticket 127.0.0.1.2009-08-04.11-42-18.1144ad5e-5ded-48ca-8871-99bb6695e5c8
On Aug 4, 6:50 pm, jayvandal wrote: > I have an error in the IMAGES in your book. I am on page 60. > this is the > Ticket > 127.0.0.1.2009-08-04.11-42-18.1144ad5e-5ded-48ca-8871-99bb6695e5c8 You need to provide the ticket contents, not the link to the ticket... F --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27970] Re: Fwd: My thoughts on web2py
Yeah maybe a complete web2py 2 rewrite. With nice and better coding... Alex Fanjul has a point IMO. On 4 aug, 20:15, Iceberg wrote: > Perhaps we will eventually have a web2py 2.0 in the way which Alex > Fanjul suggests. > > Meanwhile, we can take closer look into those "many times" of "due to > backward compatibility" issue, and see what can be adjusted. We did > that before at least for IS_STRONG. > > This time, for example, the datetime.utcnow issue can be easily > addressed by a request.utcnow, and keep request.now as is but > obsolete. Oops, problem solved without breaking backward > compatibility. > > Regards, > Iceberg > > On Aug5, 1:55am, Alex Fanjul wrote: > > > Massimo, > > Many times I have seen that, due to backward compatibility, we are > > forcing to write "messy" code in web2py applitacations. > > Evenmore some issues will never fix in the right way bacause of that... > > Won't you consider/planning to do a breakpoint with a major version > > web2py 2.0? and solve such things? > > > Python did it with 3.0, isn't it? > > > Only out of curiosity, sorry if it's reduplicate question, regards, > > Alex F > > > El 04/08/2009 9:04, mdipierro escribió: > > > > Changing now into utcnow would break backward compatibility. > > > > I do agree with you that othen people may want to use > > > > Field(,default=datetime.utcnow()) > > > > instead of > > > > Field(,default=request.now) > > > > I will add a comment about this in the book. > > > > Massimo > > > > On Aug 3, 3:22 am, Armin Ronacher wrote: > > > >> Hi, > > > >>> True. but I would not call it a race condition. We timestamp > > >>> everything with the time when a request arrives, not when it is > > >>> processed, unless specified otherwise (datetime.now() instead of > > >>> request.now) > > > >> True. But that does not make it a better idea. Also, datetime.now() > > >> should be consistently replaced with datetime.utcnow() because using > > >> anythign else than UTC data internally is problematic for various > > >> reasons. See the discussion on that topic in various i18n/l10n > > >> libraries such as babel / pytz. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27969] Re: Fwd: My thoughts on web2py
Perhaps we will eventually have a web2py 2.0 in the way which Alex Fanjul suggests. Meanwhile, we can take closer look into those "many times" of "due to backward compatibility" issue, and see what can be adjusted. We did that before at least for IS_STRONG. This time, for example, the datetime.utcnow issue can be easily addressed by a request.utcnow, and keep request.now as is but obsolete. Oops, problem solved without breaking backward compatibility. Regards, Iceberg On Aug5, 1:55am, Alex Fanjul wrote: > Massimo, > Many times I have seen that, due to backward compatibility, we are > forcing to write "messy" code in web2py applitacations. > Evenmore some issues will never fix in the right way bacause of that... > Won't you consider/planning to do a breakpoint with a major version > web2py 2.0? and solve such things? > > Python did it with 3.0, isn't it? > > Only out of curiosity, sorry if it's reduplicate question, regards, > Alex F > > El 04/08/2009 9:04, mdipierro escribió: > > > Changing now into utcnow would break backward compatibility. > > > I do agree with you that othen people may want to use > > > Field(,default=datetime.utcnow()) > > > instead of > > > Field(,default=request.now) > > > I will add a comment about this in the book. > > > Massimo > > > On Aug 3, 3:22 am, Armin Ronacher wrote: > > >> Hi, > > >>> True. but I would not call it a race condition. We timestamp > >>> everything with the time when a request arrives, not when it is > >>> processed, unless specified otherwise (datetime.now() instead of > >>> request.now) > > >> True. But that does not make it a better idea. Also, datetime.now() > >> should be consistently replaced with datetime.utcnow() because using > >> anythign else than UTC data internally is problematic for various > >> reasons. See the discussion on that topic in various i18n/l10n > >> libraries such as babel / pytz. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27968] Re: Fwd: My thoughts on web2py
Massimo, Many times I have seen that, due to backward compatibility, we are forcing to write "messy" code in web2py applitacations. Evenmore some issues will never fix in the right way bacause of that... Won't you consider/planning to do a breakpoint with a major version web2py 2.0? and solve such things? Python did it with 3.0, isn't it? Only out of curiosity, sorry if it's reduplicate question, regards, Alex F El 04/08/2009 9:04, mdipierro escribió: > Changing now into utcnow would break backward compatibility. > > I do agree with you that othen people may want to use > > Field(,default=datetime.utcnow()) > > instead of > > Field(,default=request.now) > > I will add a comment about this in the book. > > Massimo > > On Aug 3, 3:22 am, Armin Ronacher wrote: > >> Hi, >> >> >>> True. but I would not call it a race condition. We timestamp >>> everything with the time when a request arrives, not when it is >>> processed, unless specified otherwise (datetime.now() instead of >>> request.now) >>> >> True. But that does not make it a better idea. Also, datetime.now() >> should be consistently replaced with datetime.utcnow() because using >> anythign else than UTC data internally is problematic for various >> reasons. See the discussion on that topic in various i18n/l10n >> libraries such as babel / pytz. >> >> >>> True but I believe we never do that in web2py. It is also true that >>> nothing prevent the user from doing it but the same would be true with >>> other frameworks. >>> >> You're not doing it, a user might be doing that by accident or because >> he things it should work. This problem does not exist in other >> frameworks because besides web2py I don't know a single one that does >> this sort of execfile() + namespace thing or uses any other kind of >> throwaway modules. As soon as a single reference leaks from the >> execfile()'d namespace you're in big troubles and due to the open >> nature of Python this could happen very, very fast. >> >> >>> Yes but because all relevant application code is executed within a >>> context and there are no references outside the context to stuff >>> inside the context, when a request is completed, the context is >>> deleted and everything should be garbage collected. >>> >> That depends on two things. First not having a reference leaked, >> which could happen with abstract base classes and other stuff that >> uses registries or steals non-weak references. Also and more >> importantly, the file descriptor limit is very low and the majority of >> Python implementations will only collect that on the GC run (always, >> no matter where references are). Say you're opening three files per >> request and you have more than 100 requests/sec you could lose all >> file descriptors that are available before the GC even thought about >> running. >> >> Regards, >> Armin >> > > > > -- Alejandro Fanjul Fdez. alex.fan...@gmail.com www.mhproject.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27967] Ticket 127.0.0.1.2009-08-04.11-42-18.1144ad5e-5ded-48ca-8871-99bb6695e5c8
Hello, I have an error in the IMAGES in your book. I am on page 60. this is the Ticket 127.0.0.1.2009-08-04.11-42-18.1144ad5e-5ded-48ca-8871-99bb6695e5c8 Jim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27966] Web2Py and Firefox 3.5 audio tag
Just wondering if anyone has a working example of using the HTML5 tags enabled in Firefox 3.5. It should be quite simple but I just cannot make it work. I have tested the following: - Having a file in /static and pointing the the src attribute to that - Streaming a file through a controller Both of the examples give no errors, but I hear nothing. I did test that my URLs are valid (file will download). If I point the src attribute to an external hosted file (at mozilla develop) it worksso why does it not work with the same file locally? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27965] cron job website communication, find to find port?
I have a website where my cron job (present in application/cron) calls webservices hosted by localhost. I have the whole URL but except the port at which the website is hosted. I don't want to hardcode port 80, any idea how to do it? Hasanat Kazmi --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27964] Re: Ajax problem
On Aug 4, 3:50 pm, __Kyo__ wrote:
> $('#taxpayer_married').attr('onchange',
> "if($('#taxpayer_married').attr('checked'))
> $('#taxpayer_spouse_name__row').show();
> else $('#taxpayer_spouse_name__row').hide();");});
$('#taxpayer_married').change(function() {
if($('#taxpayer_married').attr('checked')) {
$('#taxpayer_spouse_name__row').show();
} else { $('#taxpayer_spouse_name__row').hide();}
});
});
> 2.- In the view, how can i reference to text box created by form like
> this in the script.
> form=FORM(TABLE(
> #TR("Lluvia", INPUT(_type="checkbox",_name="lluvia",
> _checked=False)) ,
> TR("Tipo de reporte:",SELECT(_name="tipo",requires=IS_IN_SET
> (reportes),*reportes)),
> TR("Usuario",SELECT(_type="select",_name="usuario",
> *[OPTION(x.apellidopaterno,' ',x.apellidomaterno,'
> ',x.nombre,_value=x.id)
> for x in db().select(db.usuario.ALL, orderby =
> db.usuario.apellidopaterno)])),
> TR("Fecha Inicio", INPUT
> (_name="datelimite1",_class='datetime',_id="datetlimite1")),
> TR("Fecha Final", INPUT
> (_name="datelimite2",_class='datetime',_id="datetlimite2")),
> TR("", INPUT(_type='submit',_value='Reporte'))
> ))
$('#textboxname')
Note that I see no textboxes here - I just see SELECTs & datetime
INPUTs
F
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27963] Re: r1045 breaks some upload fields
On Aug 3, 2009, at 8:33 AM, Jose wrote:
> I have just tried this in Windows XP(r1153) + python 2.5.x
>
> db.define_table('unatabla',
>Field('nombre'),
>Field('imagen', 'upload'),
> )
>
> The following mistake takes is produced when I do submit:
>
> Error traceback
> Traceback (most recent call last):
> File "E:\web2py2\gluon\restricted.py", line 178, in restricted
>exec ccode in environment
> File "E:/web2py2/applications/prueba/controllers/appadmin.py", line
> 255, in
> File "E:\web2py2\gluon\globals.py", line 101, in
>self._caller = lambda f: f()
> File "E:/web2py2/applications/prueba/controllers/appadmin.py", line
> 104, in insert
>if form.accepts(request.vars, session):
> File "E:\web2py2\gluon\sqlhtml.py", line 809, in accepts
>if not f:
> File "E:\Python25\lib\cgi.py", line 633, in __len__
>return len(self.keys())
> File "E:\Python25\lib\cgi.py", line 609, in keys
>raise TypeError, "not indexable"
> TypeError: not indexable
I took a quick look at the code behind this trace, and I can offer a
small clue. I don't know enough about what's going on to offer a
solution, but perhaps it'll ring a bell for someone who understands
the code better than I do.
Here's the code in the tree:
> elif field.type == 'upload':
> f = self.vars[fieldname]
> fd = fieldname + '__delete'
> if not f:
This used to be f == ''.
> if self.vars.get(fd, False) or not self.record:
> fields[fieldname] = ''
> else:
> fields[fieldname] = self.record[fieldname]
> continue
> elif not isinstance(f, (str, unicode)):
> (source_file, original_filename) = (f.file,
> f.filename)
> else:
> ### do not know why this happens, it should not
This comment bothers me, and I wonder if it might be related.
> (source_file, original_filename) = \
> (cStringIO.StringIO(f), 'file.txt')
> logging.warn('here')
> fields[fieldname] = field.store(source_file,
> original_filename)
> logging.warn('there')
> if field.uploadfield and not field.uploadfield==True:
> fields[field.uploadfield] = source_file.read()
> continue
>
In the failing case, f appears to be an instance of FieldStorage, from
cgi.py. It appears that Python implements "if not f" as "if not
len(f)". FieldStorage defines __len__ as "len(self.keys()), and that's
where we run into trouble.
def keys(self):
"""Dictionary style keys() method."""
if self.list is None:
raise TypeError, "not indexable"
keys = []
for item in self.list:
if item.name not in keys: keys.append(item.name)
return keys
And self.list is None unless one of two things happens:
if ctype == 'application/x-www-form-urlencoded':
self.read_urlencoded()
elif ctype[:10] == 'multipart/':
self.read_multi(environ, keep_blank_values, strict_parsing)
else:
self.read_single()
Only the first two calls (read_urlencoded() and read_multi()) set
self.list to a list. Otherwise it's None, and our 'if not f' will be
sent an exception.
If this case is expected, or at should be a detectable error
condition, then perhaps we should catch the exception and treat it as
a case of 'not f'. Or something. But as I say, I don't really know
enough about the intent of this code to go any farther.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27962] Re: chage the sort order for generated selectbox
David,
you can use
SQLField('book', db.book, requires = \
IS_IN_DB(db, 'book.code', 'book.name', orderby=db.book.id))
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27961] Re: r1045 breaks some upload fields
On 4 ago, 14:35, Fran wrote:
> On Aug 4, 3:02 pm, Jose wrote:
>
> I also found the current code still broken, despite my patch to revert
> that issue being included.
>
>
>
> > This code works well:
> > elif field.type == 'upload':
> > f = self.vars[fieldname]
> > fd = fieldname + '__delete'
> > if f == '':
> > if self.vars.get(fd, False) or not self.record:
> > fields[fieldname] = ''
> > else:
> > fields[fieldname] = self.record[fieldname]
> > continue
> > elif not isinstance(f, (str, unicode)):
> > (source_file, original_filename) = (f.file,
> > f.filename)
> > else:
> > ### do not know why this happens, it should not
> > (source_file, original_filename) = \
> > (cStringIO.StringIO(f), 'file.txt')
> > logging.warn('here')
> > fields[fieldname] = field.store(source_file,
> > original_filename)
> > logging.warn('there')
> > if field.uploadfield and not field.uploadfield==True:
> > fields[field.uploadfield] = source_file.read()
> > continue
>
> Can you send it as a diff?
>
> Copy original sqlhtml.py to sqlhtml.py.orig
> Make your changes to sqlhtml.py
> Then run:
> diff -u gluon\sqlhtml.py.orig gluon\sqlhtml.py > sqlhtml.patch
>
> F
I send it privately because I do not find like to attach files from
the group
Jose
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27959] Ajax problem
1.-
I just want to test this code, but it doesn't run very well, it
doesn't show execute the ajax function. Do i need something to run
ajax code?, this code is taken from web2py manual.
Model
db=SQLDB('sqlite://db.db')
db.define_table('taxpayer',
SQLField('name'),
SQLField('married','boolean'),
SQLField('spouse_name'))
Controller
def index():
form=SQLFORM(db.taxpayer)
if form.accepts(request.vars,session):
response.flash='record inserted'
return dict(form=form)
---View
{{extend 'layout.html'}}
{{=form}}
$(document).ready(function(){
$('#taxpayer_spouse_name__row').hide();
$('#taxpayer_married').attr('onchange',
"if($('#taxpayer_married').attr('checked'))
$('#taxpayer_spouse_name__row').show();
else $('#taxpayer_spouse_name__row').hide();");
});
2.- In the view, how can i reference to text box created by form like
this in the script.
form=FORM(TABLE(
#TR("Lluvia", INPUT(_type="checkbox",_name="lluvia",
_checked=False)) ,
TR("Tipo de reporte:",SELECT(_name="tipo",requires=IS_IN_SET
(reportes),*reportes)),
TR("Usuario",SELECT(_type="select",_name="usuario",
*[OPTION(x.apellidopaterno,' ',x.apellidomaterno,'
',x.nombre,_value=x.id)
for x in db().select(db.usuario.ALL, orderby =
db.usuario.apellidopaterno)])),
TR("Fecha Inicio", INPUT
(_name="datelimite1",_class='datetime',_id="datetlimite1")),
TR("Fecha Final", INPUT
(_name="datelimite2",_class='datetime',_id="datetlimite2")),
TR("", INPUT(_type='submit',_value='Reporte'))
))
Thanks in advance.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27960] Re: Default CRYPT() is unsecure
On Aug 4, 2009, at 6:01 AM, mdipierro wrote: > > One issue is how to implement this if we use the > request.env.remote_addr then it does not work behind a proxy, if we > use request.env.http_x_if_forwarded_for, it works only on apache and > it can spoofed anyway. I don't think we should be looking at the remote IP anyway. The problem is that these days a brute force attack can (fairly) easily be distributed across a lot of zombie machines. If we just have a timer, and don't actually disable the account, then the burden on the real user won't be that high, and then only if she tries to log in while the attack is going on. A minor advantage to using only the account name is that all we need to implement it is another field or two in the user table. > > Ideas? > > Massimo > > On Aug 4, 7:50 am, Pynthon wrote: >> Ah, nevermind then... >> >> On 4 aug, 14:47, mdipierro wrote: >> >>> This can be added easily and it does not affect backward >>> compatibility. >> >>> Massimo >> >>> On Aug 4, 7:37 am, Rob Scheibel wrote: >> Very good points in this discussion. I would like to see the addition of a processing delay added for numerous failed login attempts. This is what the larger sites are doing now - it slows down the dictionary attacks by adding 1/2 a second to each successive bad login attempt until you hit some max (i.e. 20 seconds) and then it resets (note that it should be based on Host IP but also user account in case attacks are coming from multiple IPs). Using this method it will take a LONG time to crack a relatively strong pass and most people give up and go elsewhere. It's also nice because it isn't too much of a nuicance to a user (they might be annoyed by a 20 second login delay, but they can still get in vs being locked out). >> It's also pretty easy to implement. You add a table to track the "bad IPs" and count/clear them based on timestamps. Then you add a field to the users table to track successive failed login attempts on that account and clear it on each login. >> You could also always do like LiNode is doing and lock an account by resetting the pass to a random value after x bad logins and emailing the new pass to the user. >> just flat-out locking out users for a period of time can be used to a person's advantage. Say you knew "bob" had an account on a system, but you didn't want him to be able to access it. Then you'd just try a bunch of bad passwords using his login and he'd be locked out... >> Just my $0.02. >> Thanks for the all the great work on web2py - it's been a treat to work with! >> -rob >> On Aug 2, 6:57 pm, Jonathan Lundell wrote: >> > On Aug 2, 2009, at 3:10 PM, Jonathan Lundell wrote: >> >> On Aug 1, 2009, at 9:48 AM, mdipierro wrote: >> >>> Mind that none of this has anything to do with the ability of an >>> attacker to guess the passwords to access a web2py site. This is >>> about >>> protecting the users form the administrators who may decrypt >>> their >>> hashed passords and access the users's account using their >>> decrypted >>> passwords (of an attacker who is already in the system and can >>> act as >>> the web2py administrator). But mind that the administrator >>> does not >>> even need to decrypt passwords to access them. He just log >>> request.vars.password from the model file to get the login >>> passwords >>> before they are encrypted. This is true in web2py and in any >>> other >>> web >>> based system. >> >>> I am much more concerned about a different issue: when an >>> attacker >>> wants to enter a site and repeatedly guesses the password. >>> Perhaps there should be an option in auth that locks accounts >>> after >>> many failed logins. We could have another system table to handle >>> that. >> >> How about a default STRONG as well as HMAC? If a developer >> wants to >> allow weaker passwords, let the burden be in that direction. >> >> An account-locking policy is a good idea. If the table has a >> timestamp, the lock can be temporary, at least initially. Lock >> the >> account for a n seconds after n failures. Or something like that. >> > One reason for a delay that simply imposes rate-limiting is that > permanent (or semi-permanent) locking makes for an easy DOS > attack. >> > As for a system table, wouldn't auth_user be the logical place > to put > the necessary fields? > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email
[web2py:27958] Re: How to set http "keep-alive" parameter?
On Aug 4, 2009, at 5:42 AM, mdipierro wrote: > The cherrypy server has a simsout issue under some condition. It > always worked great for me (I tried 1GB successfully) It seems to > depend on the client. What browser are you using? Can you try a > different one. If this is the same server that's serving up the web2py downloads, then we've seen several reports with different browsers. I've seen silently truncated downloads with both Safari and Firefox. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27956] Re: getting login form to use the label "Username" rather than "Email"
Perfect! Thank you. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27955] Re: r1045 breaks some upload fields
On Aug 4, 3:02 pm, Jose wrote:
I also found the current code still broken, despite my patch to revert
that issue being included.
> This code works well:
> elif field.type == 'upload':
> f = self.vars[fieldname]
> fd = fieldname + '__delete'
> if f == '':
> if self.vars.get(fd, False) or not self.record:
> fields[fieldname] = ''
> else:
> fields[fieldname] = self.record[fieldname]
> continue
> elif not isinstance(f, (str, unicode)):
> (source_file, original_filename) = (f.file,
> f.filename)
> else:
> ### do not know why this happens, it should not
> (source_file, original_filename) = \
> (cStringIO.StringIO(f), 'file.txt')
> logging.warn('here')
> fields[fieldname] = field.store(source_file,
> original_filename)
> logging.warn('there')
> if field.uploadfield and not field.uploadfield==True:
> fields[field.uploadfield] = source_file.read()
> continue
Can you send it as a diff?
Copy original sqlhtml.py to sqlhtml.py.orig
Make your changes to sqlhtml.py
Then run:
diff -u gluon\sqlhtml.py.orig gluon\sqlhtml.py > sqlhtml.patch
F
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27957] Re: ldap-auth issue (solved)
On Aug 4, 12:54 pm, Johann Spies wrote: > ldap_initialize( ldaps://stbldap01.sun.ac.za:636/??base ) > Adding port=636 solved the problem: > auth.settings.login_methods=[ldap_auth(server='stbldap01.sun.ac.za', > port=636, base_dn='ou=users,O=SU', mode='cn', secure=True)] I'll take this as a bug actually - I think ldaps:// should default to port 636, whilst ldap:// defaults to 389 (port can always be manually- specified anyway) Sending patch on this to Massimo... F --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27954] Re: getting login form to use the label "Username" rather than "Email"
On Aug 4, 3:27 pm, Fred wrote:
> How can I get the login page (myapp/
> default/user/login) to use the label "Username" rather than "Email"?
db.auth_user.email.label = T('Username')
F
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27953] getting login form to use the label "Username" rather than "Email"
I'm using LDAP authentication where users login giving their username
(uid in LDAP) and password. How can I get the login page (myapp/
default/user/login) to use the label "Username" rather than "Email"?
I tried changing myapp/views/default/user.html to have the following
but it doesn't work right. The form displays the way I want but when
I submit the form the login page just displays again.
{{extend 'layout.html'}}
{{=request.args(0).replace('_',' ').capitalize()}}
{{=form.custom.begin}}
Username: {{=form.custom.widget.email}}
Password: {{=form.custom.widget.password}}
{{=form.custom.submit}}
{{=form.custom.end}}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27952] Re: r1045 breaks some upload fields
This code works well:
elif field.type == 'upload':
f = self.vars[fieldname]
fd = fieldname + '__delete'
if f == '':
if self.vars.get(fd, False) or not self.record:
fields[fieldname] = ''
else:
fields[fieldname] = self.record[fieldname]
continue
elif not isinstance(f, (str, unicode)):
(source_file, original_filename) = (f.file,
f.filename)
else:
### do not know why this happens, it should not
(source_file, original_filename) = \
(cStringIO.StringIO(f), 'file.txt')
logging.warn('here')
fields[fieldname] = field.store(source_file,
original_filename)
logging.warn('there')
if field.uploadfield and not field.uploadfield==True:
fields[field.uploadfield] = source_file.read()
continue
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27951] Re: r1045 breaks some upload fields
On 3 ago, 15:49, Fran wrote:
>
> fixes it - patch sent to Massimo...
>
> F
Today I updated, the line 809 is corrected, but it continues producing
the mistake:
Traceback (most recent call last):
File "E:\web2py2\gluon\restricted.py", line 178, in restricted
exec ccode in environment
File "E:/web2py2/applications/prueba/controllers/appadmin.py", line
255, in
File "E:\web2py2\gluon\globals.py", line 101, in
self._caller = lambda f: f()
File "E:/web2py2/applications/prueba/controllers/appadmin.py", line
104, in insert
if form.accepts(request.vars, session):
File "E:\web2py2\gluon\sqlhtml.py", line 815, in accepts
elif not f:
File "E:\Python25\lib\cgi.py", line 633, in __len__
return len(self.keys())
File "E:\Python25\lib\cgi.py", line 609, in keys
raise TypeError, "not indexable"
TypeError: not indexable
This is in windows. In freebsd does not show the mistake, but it does
not work either.
(windows: python2.5, freebsd: python2.6)
The model is:
db.define_table('unatabla',
Field('nombre'),
Field('imagen', 'upload'),
)
To the only ones that it happens to us is this to Fran and to my?
Jose
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27950] Authentication: login and registration
Fran has helped me to get ldap-authentication working. My next
question comes from the fact that now anyone on the ldap-tree can
login and then become a registered user.
I have the following model:
==
if request.env.web2py_runtime_gae:# if running on Google App Engine
db = DAL('gae') # connect to Google BigTable
session.connect(request, response, db=db) # and store sessions and
tickets there
# session.connect(request, response, db=MEMDB(Client())
else: # else use a normal
relational database
db = DAL('sqlite://storage.sqlite') # if not, use SQLite or other DB
from gluon.contrib.login_methods.ldap_auth import ldap_auth
from gluon.tools import *
auth=Auth(globals(),db) # authentication/authorization
crud=Crud(globals(),db) # for CRUD helpers using auth
service=Service(globals()) # for json, xml, jsonrpc,
xmlrpc, amfrpc
auth.settings.login_methods=[ldap_auth(server='stbldap01.sun.ac.za',
port=636, base_dn='ou=users,O=SU', mode='cn', secure=True)]
crud.auth=auth
auth.settings.table_user =
db.define_table("auth_user",db.Field("first_name",length=128,default=""),
db.Field("last_name", length=128,default=""),
db.Field("email", length=128,default=""),
db.Field("username", length=32,default=""),
db.Field("password",'password',readable=False,
writable=False,label="Password"),
db.Field("registration_key", length=128,
writable=False, readable=False, default=""))
t = auth.settings.table_user
t.first_name.requires = IS_NOT_EMPTY()
t.username.requires = IS_NOT_EMPTY()
t.last_name.requires = IS_NOT_EMPTY()
t.password.requires = CRYPT() # password will be stored hashed
t.email.requires = [IS_EMAIL(), IS_NOT_IN_DB(db, db.auth_user.email)]
t.username.requires = [IS_NOT_IN_DB(db, db.auth_user.username)]
auth.define_tables() ### auth_user will not be redefined!
crud.settings.auth=auth # enforces authorization on crud
mail=Mail() # mailer
mail.settings.server='localhost'# your SMTP server
mail.settings.sender='johann.sp...@gmail.com' # your email
mail.settings.login=None # your credentials or None
auth.settings.mailer=mail# for user email verification
auth.settings.registration_requires_verification = True
auth.settings.registration_requires_approval = True
auth.messages.verify_email = \
'Click on the link
https://werkesel.sun.ac.za/linux_span/default/user/verify_email/%(key)s
to verify your email'
At the moment there are at least two problems:
1. Anyone in the ldap-tree can login and will then be registered
although there is no email address and registration key.
2. Any email address I type in results in an error: "Invalid email address"
I want only registered users to be able to log in. And I want the
registration to be approved by the administrator before it is valid.
How do I do it in this setup?
Why does the registration form complain about an invalid email address?
Regards
Johann
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27949] Re: Default CRYPT() is unsecure
>From what I've noticed (in regards to numerous different web services) it seems that the request IP can pretty much be spoofed if someone really wants to - so I would use it with the assumption it may be wrong (i.e. don't lock out the IP, but use it to slow down login processing). I'd also vote to not use something that only works with Apache as I think a lot of people use GAE and also Lighttpd. I don't know the full internal workings of the request variables, but I'm betting request.env.remote_addr is going to be your best bet for compatibility with all systems... Couple that with the tracking per user and it should be a pretty good deterrant against dictionary attacks I would suspect...but I'm by no means an expert...just been reading a ton about this lately and have implemented it into other php/asp/etc web services. -rob On Aug 4, 9:01 am, mdipierro wrote: > One issue is how to implement this if we use the > request.env.remote_addr then it does not work behind a proxy, if we > use request.env.http_x_if_forwarded_for, it works only on apache and > it can spoofed anyway. > > Ideas? > > Massimo > > On Aug 4, 7:50 am, Pynthon wrote: > > > Ah, nevermind then... > > > On 4 aug, 14:47, mdipierro wrote: > > > > This can be added easily and it does not affect backward > > > compatibility. > > > > Massimo > > > > On Aug 4, 7:37 am, Rob Scheibel wrote: > > > > > Very good points in this discussion. I would like to see the addition > > > > of a processing delay added for numerous failed login attempts. This > > > > is what the larger sites are doing now - it slows down the dictionary > > > > attacks by adding 1/2 a second to each successive bad login attempt > > > > until you hit some max (i.e. 20 seconds) and then it resets (note that > > > > it should be based on Host IP but also user account in case attacks > > > > are coming from multiple IPs). Using this method it will take a LONG > > > > time to crack a relatively strong pass and most people give up and go > > > > elsewhere. It's also nice because it isn't too much of a nuicance to a > > > > user (they might be annoyed by a 20 second login delay, but they can > > > > still get in vs being locked out). > > > > > It's also pretty easy to implement. You add a table to track the "bad > > > > IPs" and count/clear them based on timestamps. Then you add a field to > > > > the users table to track successive failed login attempts on that > > > > account and clear it on each login. > > > > > You could also always do like LiNode is doing and lock an account by > > > > resetting the pass to a random value after x bad logins and emailing > > > > the new pass to the user. > > > > > just flat-out locking out users for a period of time can be used to a > > > > person's advantage. Say you knew "bob" had an account on a system, but > > > > you didn't want him to be able to access it. Then you'd just try a > > > > bunch of bad passwords using his login and he'd be locked out... > > > > > Just my $0.02. > > > > > Thanks for the all the great work on web2py - it's been a treat to > > > > work with! > > > > > -rob > > > > > On Aug 2, 6:57 pm, Jonathan Lundell wrote: > > > > > > On Aug 2, 2009, at 3:10 PM, Jonathan Lundell wrote: > > > > > > > On Aug 1, 2009, at 9:48 AM, mdipierro wrote: > > > > > > >> Mind that none of this has anything to do with the ability of an > > > > > >> attacker to guess the passwords to access a web2py site. This is > > > > > >> about > > > > > >> protecting the users form the administrators who may decrypt their > > > > > >> hashed passords and access the users's account using their > > > > > >> decrypted > > > > > >> passwords (of an attacker who is already in the system and can act > > > > > >> as > > > > > >> the web2py administrator). But mind that the administrator does > > > > > >> not > > > > > >> even need to decrypt passwords to access them. He just log > > > > > >> request.vars.password from the model file to get the login > > > > > >> passwords > > > > > >> before they are encrypted. This is true in web2py and in any other > > > > > >> > > > > > >> web > > > > > >> based system. > > > > > > >> I am much more concerned about a different issue: when an attacker > > > > > >> wants to enter a site and repeatedly guesses the password. > > > > > >> Perhaps there should be an option in auth that locks accounts after > > > > > >> many failed logins. We could have another system table to handle > > > > > >> that. > > > > > > > How about a default STRONG as well as HMAC? If a developer wants to > > > > > > allow weaker passwords, let the burden be in that direction. > > > > > > > An account-locking policy is a good idea. If the table has a > > > > > > timestamp, the lock can be temporary, at least initially. Lock the > > > > > > account for a n seconds after n failures. Or something like that. > > > > > > One reason for a delay that simply imposes rate-limiting is that > > > > > permanent (or semi-permanent) locking makes f
[web2py:27948] Re: Default CRYPT() is unsecure
One issue is how to implement this if we use the request.env.remote_addr then it does not work behind a proxy, if we use request.env.http_x_if_forwarded_for, it works only on apache and it can spoofed anyway. Ideas? Massimo On Aug 4, 7:50 am, Pynthon wrote: > Ah, nevermind then... > > On 4 aug, 14:47, mdipierro wrote: > > > This can be added easily and it does not affect backward > > compatibility. > > > Massimo > > > On Aug 4, 7:37 am, Rob Scheibel wrote: > > > > Very good points in this discussion. I would like to see the addition > > > of a processing delay added for numerous failed login attempts. This > > > is what the larger sites are doing now - it slows down the dictionary > > > attacks by adding 1/2 a second to each successive bad login attempt > > > until you hit some max (i.e. 20 seconds) and then it resets (note that > > > it should be based on Host IP but also user account in case attacks > > > are coming from multiple IPs). Using this method it will take a LONG > > > time to crack a relatively strong pass and most people give up and go > > > elsewhere. It's also nice because it isn't too much of a nuicance to a > > > user (they might be annoyed by a 20 second login delay, but they can > > > still get in vs being locked out). > > > > It's also pretty easy to implement. You add a table to track the "bad > > > IPs" and count/clear them based on timestamps. Then you add a field to > > > the users table to track successive failed login attempts on that > > > account and clear it on each login. > > > > You could also always do like LiNode is doing and lock an account by > > > resetting the pass to a random value after x bad logins and emailing > > > the new pass to the user. > > > > just flat-out locking out users for a period of time can be used to a > > > person's advantage. Say you knew "bob" had an account on a system, but > > > you didn't want him to be able to access it. Then you'd just try a > > > bunch of bad passwords using his login and he'd be locked out... > > > > Just my $0.02. > > > > Thanks for the all the great work on web2py - it's been a treat to > > > work with! > > > > -rob > > > > On Aug 2, 6:57 pm, Jonathan Lundell wrote: > > > > > On Aug 2, 2009, at 3:10 PM, Jonathan Lundell wrote: > > > > > > On Aug 1, 2009, at 9:48 AM, mdipierro wrote: > > > > > >> Mind that none of this has anything to do with the ability of an > > > > >> attacker to guess the passwords to access a web2py site. This is > > > > >> about > > > > >> protecting the users form the administrators who may decrypt their > > > > >> hashed passords and access the users's account using their decrypted > > > > >> passwords (of an attacker who is already in the system and can act as > > > > >> the web2py administrator). But mind that the administrator does not > > > > >> even need to decrypt passwords to access them. He just log > > > > >> request.vars.password from the model file to get the login passwords > > > > >> before they are encrypted. This is true in web2py and in any other > > > > >> web > > > > >> based system. > > > > > >> I am much more concerned about a different issue: when an attacker > > > > >> wants to enter a site and repeatedly guesses the password. > > > > >> Perhaps there should be an option in auth that locks accounts after > > > > >> many failed logins. We could have another system table to handle > > > > >> that. > > > > > > How about a default STRONG as well as HMAC? If a developer wants to > > > > > allow weaker passwords, let the burden be in that direction. > > > > > > An account-locking policy is a good idea. If the table has a > > > > > timestamp, the lock can be temporary, at least initially. Lock the > > > > > account for a n seconds after n failures. Or something like that. > > > > > One reason for a delay that simply imposes rate-limiting is that > > > > permanent (or semi-permanent) locking makes for an easy DOS attack. > > > > > As for a system table, wouldn't auth_user be the logical place to put > > > > the necessary fields? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27947] Re: Image Manipulation
Thanks, I will give PIL a look! Thank you very much! On 4 aug, 14:44, mdipierro wrote: > I guess you can using the Python Imagel Library (PIL). You may create > an validator that watermarks on unpload. If you find out how to do it > using PIL I can help with the validator. > > Massimo > > On Aug 4, 5:39 am, Pynthon wrote: > > > Hello > > > Is it also possible to add watermarks on images with web2py? > > > Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27946] Re: Default CRYPT() is unsecure
Ah, nevermind then... On 4 aug, 14:47, mdipierro wrote: > This can be added easily and it does not affect backward > compatibility. > > Massimo > > On Aug 4, 7:37 am, Rob Scheibel wrote: > > > Very good points in this discussion. I would like to see the addition > > of a processing delay added for numerous failed login attempts. This > > is what the larger sites are doing now - it slows down the dictionary > > attacks by adding 1/2 a second to each successive bad login attempt > > until you hit some max (i.e. 20 seconds) and then it resets (note that > > it should be based on Host IP but also user account in case attacks > > are coming from multiple IPs). Using this method it will take a LONG > > time to crack a relatively strong pass and most people give up and go > > elsewhere. It's also nice because it isn't too much of a nuicance to a > > user (they might be annoyed by a 20 second login delay, but they can > > still get in vs being locked out). > > > It's also pretty easy to implement. You add a table to track the "bad > > IPs" and count/clear them based on timestamps. Then you add a field to > > the users table to track successive failed login attempts on that > > account and clear it on each login. > > > You could also always do like LiNode is doing and lock an account by > > resetting the pass to a random value after x bad logins and emailing > > the new pass to the user. > > > just flat-out locking out users for a period of time can be used to a > > person's advantage. Say you knew "bob" had an account on a system, but > > you didn't want him to be able to access it. Then you'd just try a > > bunch of bad passwords using his login and he'd be locked out... > > > Just my $0.02. > > > Thanks for the all the great work on web2py - it's been a treat to > > work with! > > > -rob > > > On Aug 2, 6:57 pm, Jonathan Lundell wrote: > > > > On Aug 2, 2009, at 3:10 PM, Jonathan Lundell wrote: > > > > > On Aug 1, 2009, at 9:48 AM, mdipierro wrote: > > > > >> Mind that none of this has anything to do with the ability of an > > > >> attacker to guess the passwords to access a web2py site. This is > > > >> about > > > >> protecting the users form the administrators who may decrypt their > > > >> hashed passords and access the users's account using their decrypted > > > >> passwords (of an attacker who is already in the system and can act as > > > >> the web2py administrator). But mind that the administrator does not > > > >> even need to decrypt passwords to access them. He just log > > > >> request.vars.password from the model file to get the login passwords > > > >> before they are encrypted. This is true in web2py and in any other > > > >> web > > > >> based system. > > > > >> I am much more concerned about a different issue: when an attacker > > > >> wants to enter a site and repeatedly guesses the password. > > > >> Perhaps there should be an option in auth that locks accounts after > > > >> many failed logins. We could have another system table to handle > > > >> that. > > > > > How about a default STRONG as well as HMAC? If a developer wants to > > > > allow weaker passwords, let the burden be in that direction. > > > > > An account-locking policy is a good idea. If the table has a > > > > timestamp, the lock can be temporary, at least initially. Lock the > > > > account for a n seconds after n failures. Or something like that. > > > > One reason for a delay that simply imposes rate-limiting is that > > > permanent (or semi-permanent) locking makes for an easy DOS attack. > > > > As for a system table, wouldn't auth_user be the logical place to put > > > the necessary fields? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27945] Re: Fwd: My thoughts on web2py
Kool, I know it sounds greedy but do you need to buy the PDF again or..? Thanks for the fast support! On 4 aug, 14:42, mdipierro wrote: > Almost done. 1-2 weeks. > > On Aug 4, 5:32 am, Pynthon wrote: > > > Nice, Massimo will there be a new book? > > > On 4 aug, 09:04, mdipierro wrote: > > > > Changing now into utcnow would break backward compatibility. > > > > I do agree with you that othen people may want to use > > > > Field(,default=datetime.utcnow()) > > > > instead of > > > > Field(,default=request.now) > > > > I will add a comment about this in the book. > > > > Massimo > > > > On Aug 3, 3:22 am, Armin Ronacher wrote: > > > > > Hi, > > > > > > True. but I would not call it a race condition. We timestamp > > > > > everything with the time when a request arrives, not when it is > > > > > processed, unless specified otherwise (datetime.now() instead of > > > > > request.now) > > > > > True. But that does not make it a better idea. Also, datetime.now() > > > > should be consistently replaced with datetime.utcnow() because using > > > > anythign else than UTC data internally is problematic for various > > > > reasons. See the discussion on that topic in various i18n/l10n > > > > libraries such as babel / pytz. > > > > > > True but I believe we never do that in web2py. It is also true that > > > > > nothing prevent the user from doing it but the same would be true with > > > > > other frameworks. > > > > > You're not doing it, a user might be doing that by accident or because > > > > he things it should work. This problem does not exist in other > > > > frameworks because besides web2py I don't know a single one that does > > > > this sort of execfile() + namespace thing or uses any other kind of > > > > throwaway modules. As soon as a single reference leaks from the > > > > execfile()'d namespace you're in big troubles and due to the open > > > > nature of Python this could happen very, very fast. > > > > > > Yes but because all relevant application code is executed within a > > > > > context and there are no references outside the context to stuff > > > > > inside the context, when a request is completed, the context is > > > > > deleted and everything should be garbage collected. > > > > > That depends on two things. First not having a reference leaked, > > > > which could happen with abstract base classes and other stuff that > > > > uses registries or steals non-weak references. Also and more > > > > importantly, the file descriptor limit is very low and the majority of > > > > Python implementations will only collect that on the GC run (always, > > > > no matter where references are). Say you're opening three files per > > > > request and you have more than 100 requests/sec you could lose all > > > > file descriptors that are available before the GC even thought about > > > > running. > > > > > Regards, > > > > Armin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27944] Re: Default CRYPT() is unsecure
This can be added easily and it does not affect backward compatibility. Massimo On Aug 4, 7:37 am, Rob Scheibel wrote: > Very good points in this discussion. I would like to see the addition > of a processing delay added for numerous failed login attempts. This > is what the larger sites are doing now - it slows down the dictionary > attacks by adding 1/2 a second to each successive bad login attempt > until you hit some max (i.e. 20 seconds) and then it resets (note that > it should be based on Host IP but also user account in case attacks > are coming from multiple IPs). Using this method it will take a LONG > time to crack a relatively strong pass and most people give up and go > elsewhere. It's also nice because it isn't too much of a nuicance to a > user (they might be annoyed by a 20 second login delay, but they can > still get in vs being locked out). > > It's also pretty easy to implement. You add a table to track the "bad > IPs" and count/clear them based on timestamps. Then you add a field to > the users table to track successive failed login attempts on that > account and clear it on each login. > > You could also always do like LiNode is doing and lock an account by > resetting the pass to a random value after x bad logins and emailing > the new pass to the user. > > just flat-out locking out users for a period of time can be used to a > person's advantage. Say you knew "bob" had an account on a system, but > you didn't want him to be able to access it. Then you'd just try a > bunch of bad passwords using his login and he'd be locked out... > > Just my $0.02. > > Thanks for the all the great work on web2py - it's been a treat to > work with! > > -rob > > On Aug 2, 6:57 pm, Jonathan Lundell wrote: > > > On Aug 2, 2009, at 3:10 PM, Jonathan Lundell wrote: > > > > On Aug 1, 2009, at 9:48 AM, mdipierro wrote: > > > >> Mind that none of this has anything to do with the ability of an > > >> attacker to guess the passwords to access a web2py site. This is > > >> about > > >> protecting the users form the administrators who may decrypt their > > >> hashed passords and access the users's account using their decrypted > > >> passwords (of an attacker who is already in the system and can act as > > >> the web2py administrator). But mind that the administrator does not > > >> even need to decrypt passwords to access them. He just log > > >> request.vars.password from the model file to get the login passwords > > >> before they are encrypted. This is true in web2py and in any other > > >> web > > >> based system. > > > >> I am much more concerned about a different issue: when an attacker > > >> wants to enter a site and repeatedly guesses the password. > > >> Perhaps there should be an option in auth that locks accounts after > > >> many failed logins. We could have another system table to handle > > >> that. > > > > How about a default STRONG as well as HMAC? If a developer wants to > > > allow weaker passwords, let the burden be in that direction. > > > > An account-locking policy is a good idea. If the table has a > > > timestamp, the lock can be temporary, at least initially. Lock the > > > account for a n seconds after n failures. Or something like that. > > > One reason for a delay that simply imposes rate-limiting is that > > permanent (or semi-permanent) locking makes for an easy DOS attack. > > > As for a system table, wouldn't auth_user be the logical place to put > > the necessary fields? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27943] Re: Auth based on UUID
If you just add a
Field('uuid','string',default=str(uuid.uuid4()), writable=False)
It should do what you ask and you can use db.export_as_csv_field to
sync remote dbs.
On Aug 4, 6:59 am, vihang wrote:
> yes, its like a federated id. but the emails are used for a different
> purpose (avatars which inturn use auth).. hence we need to have a uuid
> to unify them all... maybe the issue I am facing is too specific to my
> problem and but uuid (or similar global identifiers) would be
> interesting addition as it is becoming a necessity for most
> distributed systems
>
> On Aug 4, 12:53 pm, mdipierro wrote:
>
> > If it helps.
> > db.export_as_csv_file and db.import_as_csv_file can use uuid to sync
> > distinct databases.
>
> > But I am not sure what you need to do. Are you looking for federated
> > id?
>
> > Why not use email as uuid?
>
> > On Aug 4, 2:30 am, vihang wrote:
>
> > > Hello,
>
> > > I am currently working on an app which is distributed between
> > > different nodes. The issue is that when it comes to app related dbs, I
> > > am managing (somehow) using a seperate UUID column. But the Auth which
> > > comes with web2py does not. any ideas... I want 'building my own auth'
> > > as a last resort.
>
> > > Vihang
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27942] Re: Image Manipulation
I guess you can using the Python Imagel Library (PIL). You may create an validator that watermarks on unpload. If you find out how to do it using PIL I can help with the validator. Massimo On Aug 4, 5:39 am, Pynthon wrote: > Hello > > Is it also possible to add watermarks on images with web2py? > > Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27941] Re: Fwd: My thoughts on web2py
Almost done. 1-2 weeks. On Aug 4, 5:32 am, Pynthon wrote: > Nice, Massimo will there be a new book? > > On 4 aug, 09:04, mdipierro wrote: > > > Changing now into utcnow would break backward compatibility. > > > I do agree with you that othen people may want to use > > > Field(,default=datetime.utcnow()) > > > instead of > > > Field(,default=request.now) > > > I will add a comment about this in the book. > > > Massimo > > > On Aug 3, 3:22 am, Armin Ronacher wrote: > > > > Hi, > > > > > True. but I would not call it a race condition. We timestamp > > > > everything with the time when a request arrives, not when it is > > > > processed, unless specified otherwise (datetime.now() instead of > > > > request.now) > > > > True. But that does not make it a better idea. Also, datetime.now() > > > should be consistently replaced with datetime.utcnow() because using > > > anythign else than UTC data internally is problematic for various > > > reasons. See the discussion on that topic in various i18n/l10n > > > libraries such as babel / pytz. > > > > > True but I believe we never do that in web2py. It is also true that > > > > nothing prevent the user from doing it but the same would be true with > > > > other frameworks. > > > > You're not doing it, a user might be doing that by accident or because > > > he things it should work. This problem does not exist in other > > > frameworks because besides web2py I don't know a single one that does > > > this sort of execfile() + namespace thing or uses any other kind of > > > throwaway modules. As soon as a single reference leaks from the > > > execfile()'d namespace you're in big troubles and due to the open > > > nature of Python this could happen very, very fast. > > > > > Yes but because all relevant application code is executed within a > > > > context and there are no references outside the context to stuff > > > > inside the context, when a request is completed, the context is > > > > deleted and everything should be garbage collected. > > > > That depends on two things. First not having a reference leaked, > > > which could happen with abstract base classes and other stuff that > > > uses registries or steals non-weak references. Also and more > > > importantly, the file descriptor limit is very low and the majority of > > > Python implementations will only collect that on the GC run (always, > > > no matter where references are). Say you're opening three files per > > > request and you have more than 100 requests/sec you could lose all > > > file descriptors that are available before the GC even thought about > > > running. > > > > Regards, > > > Armin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27940] Re: How to set http "keep-alive" parameter?
The cherrypy server has a simsout issue under some condition. It always worked great for me (I tried 1GB successfully) It seems to depend on the client. What browser are you using? Can you try a different one. Massimo On Aug 4, 4:49 am, 陶艺夫 wrote: > Hi, > I don't wanna use another web server but cherrypy, I think it is capable of > serving my site. I tested my app to download a 4.2M file through > response.stream(file_name), it always terminated halfway. Is this the case > of 'Keep-alive" time is not enougth? If it is, How can I set the parameter? > python web2py -o ??? > Does above mean that? > > Thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27939] Re: Default CRYPT() is unsecure
Well, I don't understand the whole topic but if it is insecure then security goes forward backward compatible IMO. On 4 aug, 14:37, Rob Scheibel wrote: > Very good points in this discussion. I would like to see the addition > of a processing delay added for numerous failed login attempts. This > is what the larger sites are doing now - it slows down the dictionary > attacks by adding 1/2 a second to each successive bad login attempt > until you hit some max (i.e. 20 seconds) and then it resets (note that > it should be based on Host IP but also user account in case attacks > are coming from multiple IPs). Using this method it will take a LONG > time to crack a relatively strong pass and most people give up and go > elsewhere. It's also nice because it isn't too much of a nuicance to a > user (they might be annoyed by a 20 second login delay, but they can > still get in vs being locked out). > > It's also pretty easy to implement. You add a table to track the "bad > IPs" and count/clear them based on timestamps. Then you add a field to > the users table to track successive failed login attempts on that > account and clear it on each login. > > You could also always do like LiNode is doing and lock an account by > resetting the pass to a random value after x bad logins and emailing > the new pass to the user. > > just flat-out locking out users for a period of time can be used to a > person's advantage. Say you knew "bob" had an account on a system, but > you didn't want him to be able to access it. Then you'd just try a > bunch of bad passwords using his login and he'd be locked out... > > Just my $0.02. > > Thanks for the all the great work on web2py - it's been a treat to > work with! > > -rob > > On Aug 2, 6:57 pm, Jonathan Lundell wrote: > > > On Aug 2, 2009, at 3:10 PM, Jonathan Lundell wrote: > > > > On Aug 1, 2009, at 9:48 AM, mdipierro wrote: > > > >> Mind that none of this has anything to do with the ability of an > > >> attacker to guess the passwords to access a web2py site. This is > > >> about > > >> protecting the users form the administrators who may decrypt their > > >> hashed passords and access the users's account using their decrypted > > >> passwords (of an attacker who is already in the system and can act as > > >> the web2py administrator). But mind that the administrator does not > > >> even need to decrypt passwords to access them. He just log > > >> request.vars.password from the model file to get the login passwords > > >> before they are encrypted. This is true in web2py and in any other > > >> web > > >> based system. > > > >> I am much more concerned about a different issue: when an attacker > > >> wants to enter a site and repeatedly guesses the password. > > >> Perhaps there should be an option in auth that locks accounts after > > >> many failed logins. We could have another system table to handle > > >> that. > > > > How about a default STRONG as well as HMAC? If a developer wants to > > > allow weaker passwords, let the burden be in that direction. > > > > An account-locking policy is a good idea. If the table has a > > > timestamp, the lock can be temporary, at least initially. Lock the > > > account for a n seconds after n failures. Or something like that. > > > One reason for a delay that simply imposes rate-limiting is that > > permanent (or semi-permanent) locking makes for an easy DOS attack. > > > As for a system table, wouldn't auth_user be the logical place to put > > the necessary fields? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27938] Re: Default CRYPT() is unsecure
Very good points in this discussion. I would like to see the addition of a processing delay added for numerous failed login attempts. This is what the larger sites are doing now - it slows down the dictionary attacks by adding 1/2 a second to each successive bad login attempt until you hit some max (i.e. 20 seconds) and then it resets (note that it should be based on Host IP but also user account in case attacks are coming from multiple IPs). Using this method it will take a LONG time to crack a relatively strong pass and most people give up and go elsewhere. It's also nice because it isn't too much of a nuicance to a user (they might be annoyed by a 20 second login delay, but they can still get in vs being locked out). It's also pretty easy to implement. You add a table to track the "bad IPs" and count/clear them based on timestamps. Then you add a field to the users table to track successive failed login attempts on that account and clear it on each login. You could also always do like LiNode is doing and lock an account by resetting the pass to a random value after x bad logins and emailing the new pass to the user. just flat-out locking out users for a period of time can be used to a person's advantage. Say you knew "bob" had an account on a system, but you didn't want him to be able to access it. Then you'd just try a bunch of bad passwords using his login and he'd be locked out... Just my $0.02. Thanks for the all the great work on web2py - it's been a treat to work with! -rob On Aug 2, 6:57 pm, Jonathan Lundell wrote: > On Aug 2, 2009, at 3:10 PM, Jonathan Lundell wrote: > > > > > On Aug 1, 2009, at 9:48 AM, mdipierro wrote: > > >> Mind that none of this has anything to do with the ability of an > >> attacker to guess the passwords to access a web2py site. This is > >> about > >> protecting the users form the administrators who may decrypt their > >> hashed passords and access the users's account using their decrypted > >> passwords (of an attacker who is already in the system and can act as > >> the web2py administrator). But mind that the administrator does not > >> even need to decrypt passwords to access them. He just log > >> request.vars.password from the model file to get the login passwords > >> before they are encrypted. This is true in web2py and in any other > >> web > >> based system. > > >> I am much more concerned about a different issue: when an attacker > >> wants to enter a site and repeatedly guesses the password. > >> Perhaps there should be an option in auth that locks accounts after > >> many failed logins. We could have another system table to handle > >> that. > > > How about a default STRONG as well as HMAC? If a developer wants to > > allow weaker passwords, let the burden be in that direction. > > > An account-locking policy is a good idea. If the table has a > > timestamp, the lock can be temporary, at least initially. Lock the > > account for a n seconds after n failures. Or something like that. > > One reason for a delay that simply imposes rate-limiting is that > permanent (or semi-permanent) locking makes for an easy DOS attack. > > As for a system table, wouldn't auth_user be the logical place to put > the necessary fields? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27937] Re: Auth based on UUID
yes, its like a federated id. but the emails are used for a different purpose (avatars which inturn use auth).. hence we need to have a uuid to unify them all... maybe the issue I am facing is too specific to my problem and but uuid (or similar global identifiers) would be interesting addition as it is becoming a necessity for most distributed systems On Aug 4, 12:53 pm, mdipierro wrote: > If it helps. > db.export_as_csv_file and db.import_as_csv_file can use uuid to sync > distinct databases. > > But I am not sure what you need to do. Are you looking for federated > id? > > Why not use email as uuid? > > On Aug 4, 2:30 am, vihang wrote: > > > Hello, > > > I am currently working on an app which is distributed between > > different nodes. The issue is that when it comes to app related dbs, I > > am managing (somehow) using a seperate UUID column. But the Auth which > > comes with web2py does not. any ideas... I want 'building my own auth' > > as a last resort. > > > Vihang --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27936] Re: ldap-auth issue (solved)
>> auth.settings.login_methods=[ldap_auth(server='stbldap01.sun.ac.za',base_dn='ou=users,O=SU', >> mode='cn', secure=True)] $ ldapwhoami -H ldaps://stbldap01.sun.ac.za -D 'cn=jspies,ou=users,O=SU' -x -v -W -n Enter LDAP Password: ldap_initialize( ldaps://stbldap01.sun.ac.za:636/??base ) Result: Success (0) Adding port=636 solved the problem: auth.settings.login_methods=[ldap_auth(server='stbldap01.sun.ac.za', port=636, base_dn='ou=users,O=SU', mode='cn', secure=True)] Thanks Fran for giving direction to my thought processes. Regards Johann --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27935] Re: Google seems to know Web2Py
Yes, I will try to post and example tonight.
I believe your students will REALLY like this...
Here are a few DALnr snippets till then:
In gql.py
from google.appengine.ext import db as google_db
from google.appengine.ext.db import polymodel as pm # DLypka Mod to
support PolyModel
:
:
class MyGAEBaseTreeLevel(pm.PolyModel): #DLypka Mod
selflinkPrev = google_db.SelfReferenceProperty
(collection_name='selflinksPrev')
selflinkNext = google_db.SelfReferenceProperty
(collection_name='selflinksNext')
class MyGAEBaseTreeLevelSegment(pm.PolyModel): #DLypka Mod This
entity is a child of MyGAEBaseTreeLevel
linkToTreeLevel = google_db.ReferenceProperty(MyGAEBaseTreeLevel,
required=False, collection_name='linksToTreeLevel')
In Method def _select(self, *fields, **attributes):
:
:
#tablename = table.kind() # DLypka commented out for
PolyModel support
tablename = table.class_name() # DLypka Patch for PolyModel
support
In Method def _create(self):
:
:
if self._tablename == 'MyGAEBaseTreeLevel':
self._tableobj = classobj(self._tablename,
(MyGAEBaseTreeLevel, ), myfields)
elif self._tablename == 'MyGAEBaseTreeLevelSegment':
self._tableobj = classobj(self._tablename,
(MyGAEBaseTreeLevelSegment, ), myfields)
elif self._tablename == 'MyGAEBaseTreeItem':
self._tableobj = classobj(self._tablename,
(MyGAEBaseTreeItem, ), myfields)
else:
self._tableobj = classobj(self._tablename,
(google_db.Model, ), myfields)
return None
In db.py:
# Create a Parent Entity:
myTreeLevelNativeInstance00keys = db.TreeLevel.insertNative(level=0,
name='TreeLevel_01') # I cloned insert() but I return a dict() with
the native ref as well as id
myTreeLevelNativeInstance00 = myTreeLevelNativeInstance00keys
['nativeRef']
myTreeLevelNativeInstance00id = myTreeLevelNativeInstance00keys['id']
rows=db(db.TreeLevel.id > 0).select()
for row in rows:
myTreeLevelInstance00 = row # NOTE: There is only a single row
here, so myTreeLevelInstance00 will be the row we just inserted into
the web2py DAL
myTreeLevelSegmentNativeInstance00_00keys =
db.TreeLevelSegment.insertNative(idTreeLevel =
myTreeLevelNativeInstance00id, level=0, name='TreeLevelSegment_00_01')
myTreeLevelSegmentNativeInstance00_00 =
myTreeLevelSegmentNativeInstance00_00keys['nativeRef']
myTreeLevelSegmentNativeInstance00_00.linkToTreeLevel=myTreeLevelNativeInstance00
# <=== NOTE This is the Interesting part !!! ===
myTreeLevelSegmentNativeInstance00_00.put() # This rewrites (updates)
the entity
links1 = myTreeLevelNativeInstance00.linksToTreeLevel # <=== NOTE:
This is EXTREMELY Interesting!! - this property was AUTOMATICALLY
maintained by the automatic bidirectional nature of the
ReferenceProperty, so that the 'parent' has a list of refs to its
related children, without any explicit code to add them!!!
# links1 is a google.appengine.ext.db.query
# It is a db.Query
# Here you should loop on links1 which is a column on the parent
entity and see what you get
for key in links1:
childref = key # childref is (magically) a TreeLevelSegment which
is a child of TreeLevel
-- End of DALnr Snippets for GAE ---
- Dave Lypka.
On Aug 4, 12:27 am, mdipierro wrote:
> Can you show us an example?
>
> On Aug 3, 9:01 am, dlypka wrote:
>
>
>
> > PolyModel enables true polymorphic behavior when querying objects
> > whose classes are derived from other classes.
> > So, in the retrieved instance, all fields of all classes at and above
> > the target class are available to the retrieved instance.
>
> > When PolyModel is not used as the base class, then the query only
> > returns the attributes of the queried class.
> > Attributes of inherited classes are uninitialized.
>
> > So using PolyModel as the base class, the web2py DAL classes can carry
> > along GAE-specific attributes in base classes,
> > one of the most useful being the Reference attribute, which will link
> > together related instances so that GAE will return them in a single
> > query.
> > Also, Reference gives automatic bidirectional links.
>
> > On Aug 2, 1:17 pm, mdipierro wrote:
>
> > > What is PolyModel? How is different than what DAL already does when
> > > running on GAE?
>
> > > On Aug 2, 11:33 am, dlypka wrote:
>
> > > > I just got an experimental version of T3 to work with the PolyModel
> > > > base class in GAE.
> > > > That gives inherited Classes.
> > > > So GAE is Quite Amazing.
>
> > > > I almost have my own DALnr ('nr' = non relational) for web2py working
> > > > with GAE now.
> > > > It is using my 'Phantom' Field concept (special table fields in a
> > > > db.define_table(...) which do native GAE operations but are not
> > > > otherwise part of the list of columns for that web2py table)
>
> > > > In particular I got PolyModel to work together with the Reference
> > > > f
[web2py:27934] Image Manipulation
Hello Is it also possible to add watermarks on images with web2py? Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27933] Re: Fwd: My thoughts on web2py
Nice, Massimo will there be a new book? On 4 aug, 09:04, mdipierro wrote: > Changing now into utcnow would break backward compatibility. > > I do agree with you that othen people may want to use > > Field(,default=datetime.utcnow()) > > instead of > > Field(,default=request.now) > > I will add a comment about this in the book. > > Massimo > > On Aug 3, 3:22 am, Armin Ronacher wrote: > > > Hi, > > > > True. but I would not call it a race condition. We timestamp > > > everything with the time when a request arrives, not when it is > > > processed, unless specified otherwise (datetime.now() instead of > > > request.now) > > > True. But that does not make it a better idea. Also, datetime.now() > > should be consistently replaced with datetime.utcnow() because using > > anythign else than UTC data internally is problematic for various > > reasons. See the discussion on that topic in various i18n/l10n > > libraries such as babel / pytz. > > > > True but I believe we never do that in web2py. It is also true that > > > nothing prevent the user from doing it but the same would be true with > > > other frameworks. > > > You're not doing it, a user might be doing that by accident or because > > he things it should work. This problem does not exist in other > > frameworks because besides web2py I don't know a single one that does > > this sort of execfile() + namespace thing or uses any other kind of > > throwaway modules. As soon as a single reference leaks from the > > execfile()'d namespace you're in big troubles and due to the open > > nature of Python this could happen very, very fast. > > > > Yes but because all relevant application code is executed within a > > > context and there are no references outside the context to stuff > > > inside the context, when a request is completed, the context is > > > deleted and everything should be garbage collected. > > > That depends on two things. First not having a reference leaked, > > which could happen with abstract base classes and other stuff that > > uses registries or steals non-weak references. Also and more > > importantly, the file descriptor limit is very low and the majority of > > Python implementations will only collect that on the GC run (always, > > no matter where references are). Say you're opening three files per > > request and you have more than 100 requests/sec you could lose all > > file descriptors that are available before the GC even thought about > > running. > > > Regards, > > Armin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27932] How to set http "keep-alive" parameter?
Hi, I don't wanna use another web server but cherrypy, I think it is capable of serving my site. I tested my app to download a 4.2M file through response.stream(file_name), it always terminated halfway. Is this the case of 'Keep-alive" time is not enougth? If it is, How can I set the parameter? python web2py -o ??? Does above mean that? Thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27931] Re: ldap-auth issue
Apologies. I was testing from two different computers. On the one (where the web2py server was running) it was working and I did not see that the one from which I pasted the entries was failing. The following worked (same string with a 'TLS_REQCERT allow' added to /etc/ldap/ldap.conf): $ ldapwhoami -H ldaps://stbldap01.sun.ac.za -D 'cn=jspies,ou=users,O=SU' -x -v -W -n Enter LDAP Password: ldap_initialize( ldaps://stbldap01.sun.ac.za:636/??base ) Result: Success (0) Regards Johann 2009/8/4 Fran : > > > We need a working string in order to know how to code that within > Web2Py. > All of these have failed... > > F > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27930] Re: hidden fields
On Aug 4, 12:28 am, mattynoce wrote: > request.vars['hiddenfield'] = val > immediately before the form.accepts part. i could confirm that it set > properly and that request.vars found hiddenfield, but it still > wouldn't update (even if i set db.table.hiddenfield.writable=True). > something seems wrong there. is that by design? it was not a part of > the sqlform but it becomes a part of request.vars immediately before > the if form.accepts(request.vars, session), so i don't understand why > it would be left behind. Because it's not in 'form' As Massimo says you can use: form.vars[hiddenfield] = request.vars[hiddenfield] > next i tried was your suggestion about processing the field manually > in the "if form.accepts" part. the problem i'm finding is that > form.accepts returns True or False rather than [id] or False. so i did > this: > a=form.accepts(request.vars,session) > if a: > ... > but when i printed a, it printed not as 1 or 2 but as True. so it > doesn't seem to be returning the identity that i would need in order > to process an update. am i missing something there? What I meant by 'processing' was the validation & DB insert, not using form.accepts (that applies to 'form', this var wasn't in 'form'). Looking at this again, I guess that's hard for a create form...an update form would be fine... F --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27929] Re: ldap-auth issue
On Aug 4, 10:09 am, Johann Spies wrote: > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > Additional info: Unrecognized extended operation > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > I hope the information above will help. We need a working string in order to know how to code that within Web2Py. All of these have failed... F --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27928] Re: ldap-auth issue
Thanks Fran for your reply.
2009/8/3 Fran :
>> db.Field("password",'password',readable=False, label="Password"),
>
> Add writable=False to make it not show in the register form.
Thanks. I am learning...
>
> My guess is that this is an LDAP failure.
> Try the LDAP login from the CLI on the same machine as the server (to
> check for Firewall issues).
> The relevant string to test from what you have above is:
> ldapwhoami -x -D cn=username,ou=users,O=SU -W -H
> ldaps://stbldap01.sun.ac.za:389
> (replace 'username' with your username)
$ ldapwhoami -x -D 'cn=jspies,ou=users,O=SU' -W -H
ldaps://stbldap01.sun.ac.za:369
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
and
$ ldapwhoami -x -D 'cn=jspies,ou=users,O=SU' -W -H ldaps://stbldap01.sun.ac.za
Enter LDAP Password:
ldap_parse_result: Protocol error (2)
additional info: Unrecognized extended operation
Result: Protocol error (2)
Additional info: Unrecognized extended operation
but
$ ldapwhoami -H ldaps://stbldap01.sun.ac.za -D
'cn=jspies,ou=users,O=SU' -x -v -W -n
Enter LDAP Password:
ldap_initialize( ldaps://stbldap01.sun.ac.za:636/??base )
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
>
> If you get a working LDAP connection string, then we can let you know
> how to do this within ldap-auth (which may require amending the ldap-
> auth to cater for the option(s) you need)
I hope the information above will help.
Thanks again.
Regards
Johann
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27927] Re: Auth based on UUID
If it helps. db.export_as_csv_file and db.import_as_csv_file can use uuid to sync distinct databases. But I am not sure what you need to do. Are you looking for federated id? Why not use email as uuid? On Aug 4, 2:30 am, vihang wrote: > Hello, > > I am currently working on an app which is distributed between > different nodes. The issue is that when it comes to app related dbs, I > am managing (somehow) using a seperate UUID column. But the Auth which > comes with web2py does not. any ideas... I want 'building my own auth' > as a last resort. > > Vihang --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27926] chage the sort order for generated selectbox
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I have two tables, table "book" with fields "code" and "name", filled
with values e.g.:
id codename
1 bz Book 1
2 f4r Other book
and the second table with field:
SQLField('book', db.book, requires = \
IS_IN_DB(db, 'book.code', 'book.name'))
Web2py is able to generate a form with the selectbox for the field
"book", it is good. But I need other sort order of entries in the
selectbox, it should be ordered by book.id whereas the name displayed
should be the 'name' as defined above. Is it possible?
Thanks!
David
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkp37LUACgkQ3oCkkciamVFzpgCfe9RZzV5HLZg1gouac1Gzlz0L
FoAAn08JFJNQi3Sogg4dn+7833bh86lz
=oL/m
-END PGP SIGNATURE-
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---
[web2py:27925] Auth based on UUID
Hello, I am currently working on an app which is distributed between different nodes. The issue is that when it comes to app related dbs, I am managing (somehow) using a seperate UUID column. But the Auth which comes with web2py does not. any ideas... I want 'building my own auth' as a last resort. Vihang --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
[web2py:27924] Re: Fwd: My thoughts on web2py
Changing now into utcnow would break backward compatibility. I do agree with you that othen people may want to use Field(,default=datetime.utcnow()) instead of Field(,default=request.now) I will add a comment about this in the book. Massimo On Aug 3, 3:22 am, Armin Ronacher wrote: > Hi, > > > True. but I would not call it a race condition. We timestamp > > everything with the time when a request arrives, not when it is > > processed, unless specified otherwise (datetime.now() instead of > > request.now) > > True. But that does not make it a better idea. Also, datetime.now() > should be consistently replaced with datetime.utcnow() because using > anythign else than UTC data internally is problematic for various > reasons. See the discussion on that topic in various i18n/l10n > libraries such as babel / pytz. > > > True but I believe we never do that in web2py. It is also true that > > nothing prevent the user from doing it but the same would be true with > > other frameworks. > > You're not doing it, a user might be doing that by accident or because > he things it should work. This problem does not exist in other > frameworks because besides web2py I don't know a single one that does > this sort of execfile() + namespace thing or uses any other kind of > throwaway modules. As soon as a single reference leaks from the > execfile()'d namespace you're in big troubles and due to the open > nature of Python this could happen very, very fast. > > > Yes but because all relevant application code is executed within a > > context and there are no references outside the context to stuff > > inside the context, when a request is completed, the context is > > deleted and everything should be garbage collected. > > That depends on two things. First not having a reference leaked, > which could happen with abstract base classes and other stuff that > uses registries or steals non-weak references. Also and more > importantly, the file descriptor limit is very low and the majority of > Python implementations will only collect that on the GC run (always, > no matter where references are). Say you're opening three files per > request and you have more than 100 requests/sec you could lose all > file descriptors that are available before the GC even thought about > running. > > Regards, > Armin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~--~~~~--~~--~--~---
