Sorry for the confusion. I was not talking about T2/T3 etc... The t2.auth is deprecated. web2py users should not use t2.
So far I was talking about class gluon.tools.Auth that ships. The web2py system administrator is god. He can do whatever he wants. There is only one. It is not managed by gluon.tools.Auth because he needs to authenticate whether or not the database is up. The application administrator is a role defined by the app with gluon.tools.Auth. He can do what the app allows him to do. Different apps by default have different sessions, databases, cookies, etc. The administrators of two apps do not share anything. T3 and kpax are old apps and they come with their own obsolete authentication methods (t2.ath) which are not as good as gluon.tools.Auth althought there are similarities. Massimo On 1 Lug, 01:45, GoldenTiger <goldenboy...@gmail.com> wrote: > Yes I know this about T3, 3 levels, ok. > What i wonder is if two different wiki admins (or users) of two > different wiki apps could share data in some way > (sessions,files,db...). Since wiki admin/users can write python code > editing pages, could users access shared data? > > Another independient T3 cuestion: > We have T3/models/db.py, where > > is_admin=(t2.logged_in and (not settings.administrator_emails or > t2.person_email in settings.administrator_emails)) > > According that condition, if on production server, admin disable > settings.administrator_emails, then if a new user registers, we have > is_admin=True for new user, haven't? > > On 1 jul, 07:57, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > On 30 Giu, 23:57, GoldenTiger <goldenboy...@gmail.com> wrote: > > > > I'm still thinking about it. I was raised a small question regarding > > > the cooperation of applications (page 126 of book). > > > The applications can share tables, sessions, files, import modules > > > from other applications, call other's applications actions with > > > exec_environment ... > > > > Is there a way to prevent my application to share this information? > > > If an application poorly designed is vulnerable ¿can others > > > applications protect against this? > > > One web2py instance can run multiple apps. They all run under the same > > os credentials as web2py and therefore they can see and edit each > > other files. We simply provide some API's to allow one app to open a > > session from another app. There is nothing web2py specific about this. > > In any other web framework/system if you run two web apps as www-data, > > they can read each other files. > > If you need separation you can run two or more web2py instances under > > different credentials. > > > > I have not very clear whether a web2py installation is designed to be > > > programmed by a single development team, or if possible more than one > > > webmaster at the same time. > > > Let's say we have a system with multiple applications such as wikis T3- > > > like, where each wiki has its own administrator. > > > Is web2py not intended for that? > > > We need two distinguish three level: the os level, the web2py admin > > level, the application level. > > At the os level of course you can have multiple users. > > At the web2py admin level there is a single user and we refer to him > > as "administrator". The administrator can upload apps, create app, > > edit apps. We have a single administrator because things would get > > very messy if two people where to edit the same app at the same time > > (although we have mechanisms to detect this, notify the administrator > > and revert changes). > > At the app level, each app can have arbitrary users and the > > authentication for different apps is separate (different groups, > > different users, different permissions, etc.) > > > So in the case of a wiki you would have two types of "administrator": > > the web2py administrator who deployed the wiki (for two coexisting > > wikis, the same administrator), the wiki administrator who has special > > permission on the wiki content (this can be different for different > > coexisting wikis). > > > Auth is the app-level authentication mechanism. the "web2py > > administrator" is not managed by Auth. > > > Does this make sense? > > > > On 1 jul, 02:15, GoldenTiger <goldenboy...@gmail.com> wrote: > > > > > > I disagree but probably I did not explain this very well. web2py has > > > > > two things it calls session. One is the general session managed via > > > > > cookie session_id. One is the authentication session stored into the > > > > > general session file. When a user logs out the authentication session > > > > > information into the general session is deleted. If an attacker where > > > > > to intercept the cookie session_id and try to use it to gain access to > > > > > the system, it would not work. The session_id is used for the general > > > > > session and it does not expire because when the user logs in again, if > > > > > the user had a state stored in the session file, you want that state > > > > > to be retrieved. > > > > > Well, this is my point of view: > > > > I don't know if i'm wrong. If i understanded it well, this concept > > > > could be classified as a design concept, do you agree? > > > > design flaws are the most complex aspect of security > > > > personally I am doubtful about the explanation above, maybe I don't > > > > understand very well > > > > anyway it's the game of "I can't find any flaw at this moment, but you > > > > can't demonstrate it hasn't" > > > > Vulns like SQL injection could be enumerated and tested by a computer > > > > in a lot of possibilities, but design flaws couldn't, since lies on > > > > human logic > > > > History is full of stories about design flaws. The following is a > > > > representative > > > > case.http://www.seattlepi.com/local/373426_insecure04.html > > > > > Sorry, I am very paranoid ^^ > > > > > On 30 jun, 22:06, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > > > this is how I make my hmac_kay > > > > > > >>> import uuid > > > > > >>> print 'sha512:'+str(uuid.uuid4()) > > > > > > web2py has a function in gluon/admin.py, app_create('name',request) > > > > > that clones welcome and replaces hmac_key='<....>' with a random key > > > > > generated as above. > > > > > > From a web2py shell you can also do > > > > > > >>> from gluon.admin import app_create > > > > > >>> app_create('mynewapp',request) > > > > > > I would not know how to make this transparent. If you have any idea > > > > > please let me know. I agree that this is undocumented. > > > > > > On 30 Giu, 15:01, Yarko Tymciurak <resultsinsoftw...@gmail.com> wrote: > > > > > > > On Jun 30, 2:44 pm, Craig Younkins <cyounk...@gmail.com> wrote: > > > > > > > > If you'd like this moved to the developers list, just approve my > > > > > > > application > > > > > > > and reply there. > > > > > > > > > When I say that MD5 is the default that applies only to the > > > > > > > > case that > > > > > > > > a hmac_key is not specified. This is 1) for backward > > > > > > > > compatibility; 2) > > > > > > > > because without a key/salt sha512 and md5 are vulnerable to the > > > > > > > > same > > > > > > > > dictionary attacks. > > > > > > > > Hmm.... Well, I'm looking at the CRYPT class and it appears that > > > > > > > in order to > > > > > > > use HMAC the *caller* needs to pass in the key parameter. > > > > > > > Grepping the > > > > > > > source tree I've found a few places where the caller does not > > > > > > > supply the > > > > > > > key: > > > > > > > > applications/admin/models/access.py:55 > > > > > > > applications/admin/controllers/default.py:78 > > > > > > > gluon/main.py:480 > > > > > > > gluon/main.py:495 > > > > > > > gluon/validators.py:2344 > > > > > > > > I am of course unfamiliar with the internals of the project, but > > > > > > > it would > > > > > > > appear to me that admin passwords are never HMAC'd. Can you > > > > > > > confirm? > > > > > > > ... interesting discussion ---- Let me FIRST point out some things > > > > > > Craig mentions which should not fall by the wayside: > > > > > > > 1. -- There is no documented way to generate {an appropriate} > > > > > > hmac_key: > > > > > > ==> This is true; One major way to alleviate this would be to > > > > > > have an admin function that could be called manually (take your > > > > > > pick: > > > > > > to do the replacement, as gluon/admin.py:app_create() does, which > > > > > > would need a search/replace --- or better, just give a popup with a > > > > > > newly formed key an admin could readily copy/paste. > > > > > > > ==> This is also inconsistently applied --- for example, if you > > > > > > pack "welcome" app, and then (as you might with apps from other > > > > > > sites, such as web2py.com, or other users) install it as a newly > > > > > > (re)named application, <your key here> persists. At the > > > > > > surface, the same thing app_create() is doing could be done in > > > > > > app_install(), but this too would be prone to inconsistencies (i.e. > > > > > > the user you get an app from to test for them will have already > > > > > > installed their own hmac_key, so the kind of replacement that > > > > > > app_create() does - which depends on a "magic string" in the > > > > > > template > > > > > > app, will fail. > > > > > > > A better solution would be to make this completely transparent --- a > > > > > > little thinking about this should come to a solution (hmac_key is > > > > > > currently persisted in a source file...) > > > > > > > ... Good discussion, guys - lovely to see this! > > > > > > > - Yarko > > > > > > > > I suggest that the key be pulled in from the configuration inside > > > > > > > CRYPT so > > > > > > > that the caller isn't required to pass it in. I would also > > > > > > > suggest that the > > > > > > > hash method be placed in configuration. Consolidating the > > > > > > > configuration of > > > > > > > security mechanisms greatly aids in a security review. If it were > > > > > > > consolidated, a reviewer would only have to look at the default > > > > > > > configuration. In it's current state, a reviewer needs to look at > > > > > > > all the > > > > > > > callers of CRYPT to determine the security of CRYPT. > > > > > > > > I realize some of my suggestions may prove difficult to support > > > > > > > backwards > > > > > > > compatibility. In many cases this can be worked around to > > > > > > > implement and > > > > > > > start using newer, safer security controls while maintaining > > > > > > > support for > > > > > > > older methods. In some cases it's more difficult than others. > > > > > > > > > If you use "admin" to create a new app, the '<your secret key>' > > > > > > > > is > > > > > > > > automatically replaced with something like > > > > > > > > Thanks for clarifying! This works. > > > > > > > > > > * Do not use cgi.escape for HTML escaping because it does not > > > > > > > > > escape > > > > > > > > > single quotes and may lead to XSS - Seehttp:// > > > > > > > >www.pythonsecurity.org/wiki/web2py/#cross-site-scripting-xss> > > > > > > > >and http://www.pythonsecurity.org/wiki/cgi/ > > > > > > > > > I assume you refer to attribute escaping. When using helpers > > > > > > > > like > > > > > > > > > {{=A(link,_href=url)}} then link is > > ... > > leggi tutto
