Still working on this... not sure what the right way but... if app2 delegates authentication to app1 and user changes profile on app1, at next login his record on app2 is overwritten (the id and registration_id stay the same but the other fields in common between apps are updated)
On May 23, 9:43 pm, Massimo Di Pierro <[email protected]> wrote: > I moved from Cas 1 provider to Cas 2 provider. Changed the notation a > bit: > > Say you has two apps running on > domainshttp://domain1/app1andhttp://domain2/app2(where domain1 and domain2 > can be 127.0.0.1:8000) > > # In app1/models/db.py > auth = Auth(db=db) > auth.cas_domains.append('http://domain2') # allow app2 from domain2 > auth.define_tables(username=True) > > # In app2/models/db.py > auth = Auth(db=db,cas_provider='http://domain1/app1/default/user/ > cas') > auth.define_tables(username=True) > > username=True is optional. > > On May 23, 10:15 am, Massimo Di Pierro <[email protected]> > wrote: > > > > > > > > > We should make a list of operations we want to support. > > > Anyway, I have one more revision. > > > Say you has two apps running on > > domainshttp://domain1/app1andhttp://domain2/app2(wheredomain1 and domain2 > > can be 127.0.0.1:8000) > > Now you simply do: > > > # In app1/models/db.py > > > auth = Auth(db=db) > > auth.cas_domains.append('http://domain2') # allow app2 from domain2 > > auth.define_tables(username=True) > > > # In app2/models/db.py > > > auth = Auth(db=db,cas_provider='http://domain1/app1/default/user') > > auth.define_tables(username=True) > > > At voila' app2 will use app1 for authentication. > > username=True is optional. > > > Massimo > > > On May 23, 9:45 am, Michele Comitini <[email protected]> > > wrote: > > > > Could CAS server answer to questions such as "is operation bar allowed > > > to user foo"? > > > > The list of operations is CAS server dependent, the consumer can ask > > > only for those... > > > > mic > > > > 2011/5/23 Massimo Di Pierro <[email protected]>: > > > > > I have been thinking about this but issue is, how should groups be > > > > identified? By their name? The consumer app does not have the same > > > > auth_group table. What if it has a group with the same name as a group > > > > in the provider app? > > > > > Anyway... as it ism CAS (and cas in Auth) has a problem. Any consumer > > > > can authenticate with it and therefore it will reveal information > > > > about the user (for example the username and email). There are two > > > > ways to restrict this: 1) have the provider filter consumers by IP/ > > > > domain; 2) have the user decide whether to authenticate with the > > > > consumer (as in OpenID). I think 1 is more appropriate for CAS and > > > > easier to implement. > > > > > On May 23, 7:24 am, Ross Peoples <[email protected]> wrote: > > > >> I am not that familiar with CAS, but it might be useful in some cases > > > >> to > > > >> know what groups the user is a member of in the remote web2py > > > >> installation. > > > >> For example, if there is an 'Administrators' group that should have > > > >> access > > > >> to everything, then you wouldn't have to set up groups and permissions > > > >> for > > > >> every single app that uses the remote Auth service.
