this really seems to point out the larger problem at work here. a browser-session needs to have multiple access capabilities on a single page, especially within a "single sign on" framework. The session owner might be part of multiple domains, with differing roles too, so that needs to be feasible without constantly logging in and logging out.
another message indicated that there was no way to add external e-mail addresses to a mailing list in apps - another one earlier somewhere else said that this would be accomplished as a hack to 'groups' -- yet another person on another list has said that they've scrapped a project based on notebooks because of these types of access control issues with accounts and domains. even simple calendar/event- notification functions are upside down or backwards in many real world use-cases sounds like developers are hitting a brick wall with implementations because of these types of problems -- the features are not nearly what they appear to be once they are actually put to use.. at least google is somewhat concerned about this by providing good release notes, help files, and these forums thru which we can all comment on the issues. but it also shows a need for a bit more quality- assurance review for development procedures and product deployment and testing. g-mail has been very successful because it's a solid model of a known application. but with app-engine style development where one can mix and match components to form larger workflows - all of the components need to work together on the same page or session, plus multiple instances of the same - this requires a more sensible and well documented approach to authentication and access control at a session and component level, to say nothing about how URLs are constructed... in short: accounts have rights in accessing and implementing components and components have capabilities for accounts to access - thats it - all of it should be browsable and configurable, including the standard assumptions in the pre-packaged applications such as spreadsheets, docs, calendars, etc -- a "googleMyAdmin" similar to the php webtop for MySql, or a directory browser/editor for LDAP servers ) -- maybe this exists already somewhere in the google API reference or is something someone is working on.. ? On May 26, 12:38 am, Vladimir Solomenchuk <[EMAIL PROTECTED]> wrote: > > In step 6, when the ID provider passes the SAML response back to the > > web application, are you grabbing the SAML response and making a > > cookie out of that? I'm thinking if you could do that then you could > > introduce the data in that cookie into the bespoke apps(widgets) in > > the site to authenticate with google. > > I have no access to user data (because different domains) > Looks like every service has its own authentication.For example, you > have to visit calendar page for work with calendar widget and google > talk page for google talk. Even on ig page calendar widget will not > work without visiting calendar page. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Apps APIs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-apps-apis?hl=en -~----------~----~----~----~------~----~------~--~---
