I apologize if I made it look like you were attacking the idea. I haven't yet had time to get into wave development. I know nothing at all about OAuth.
I guess it would make sense to create the post (collaboratively or otherwise) before adding the robot. Perhaps the gadget could be inserted in a private wavelet to the robot, thereby removing the storage requirements for the credentials (my original idea would have been to receive some sort of key from the blog server based on the credentials [nobody would ever have access to this except the robot] and store that [to prevent security issues of storing actual credentials], in some sort of robot-only database along with the waveid, and send it with requests to the blog server.) As for collaborative blogging, I hadn't thought about this. In this case, all non-editor comments would be made from the blog site, (and the robot would create the appropriate wavelets). Perhaps this could be based on whether the gadget is in a private wavelet to the robot or a public one. (can the robot tell who is privy to a private wavelet?) (and can the viewers of a private wavelet be changed at a later point if somebody is abusing their edit rights?) As for authenticating wave events, the key mentioned above could be stored in the gadget (which would only be exposed to the individuals who have edit rights). If this key is intercepted by a 3rd party, it would be equivalent of user/pass being intercepted on a login form. The correct key must match up with the correct waveid in the robots database in order for the result to be pushed. (perhaps the robot would create an alert wavelet when it receives a call that doesn't match) The gadget would also probably need some sort of control panel (to add the robot, but not publish yet, or to pause publishing of main post while others check the changes or something of the sort). Christopher Also, should be move our discussion to a wave to reduce traffic here? anybody object to our discussions in here? On Mon, Nov 9, 2009 at 2:43 PM, David Nesting <da...@fastolfe.net> wrote: > I'm not attacking the idea at all. Like I said, I'm working on the same > thing, so I'd love to hear your ideas on some of these. > > On Mon, Nov 9, 2009 at 11:05 AM, Christopher Baker > <slithyto...@gmail.com>wrote: > >> 2. Use a gadget that goes with the robot (can the robot add it?) that you >> can fill in information (maybe even store a cookie for next time). >> > > This sounds reasonable, but what would happen to the credentials? Where do > they get stored? How would you associate those credentials with the content > you mean to publish? > > Assuming you're abandoning OAuth for a moment, and prefer to deal directly > with usernames and passwords, that information starts out in the gadget. > You'd presumably post that to your robot (as a regular HTTP request, not > via the wave), but the wave's content would not accompany that. Your robot > would still need to connect, somehow, the content that it's receiving events > for, and the credentials gathered by the gadget. The wave ID would seem to > be the logical way to do that, but you still have to authenticate the event > itself somehow. > > >> 3. 2 would contain this information (URL, user, pass, title=subject). My >> thoughts would be to add robot as first participant, have robot store info >> then clear gadget to protect info before adding more participants. >> > > You can't enforce that the robot be the first participant. What should > happen if the robot is not the first participant? What if it's an unrelated > person adding the robot? If you create a gadget to get the user to > authenticate, and to decide where to send the content, what happens when > someone else fills in the form and submits it before you get a chance to? > Should both attempts to publish the wave succeed? (I'd say yes, and that > this would be a feature.) If not, how does the owner of a wave recover from > that situation? > > >> 4. To fake events, they need your password. >> > > Robot events are wholly independent of the gadget. The gadget does not > see changes to the content, and cannot provide those changes to the robot > along with authentication credentials. The best you can do is have the > gadget provide the credentials to the robot, and have the robot > independently receive and act upon the events, somehow connecting the event > to the credentials stored earlier. > > The problem is that if I know your wave ID, I can forge events to your > robot and convince your robot that changes are being made to a wave. You > can't store authentication credentials in the wave itself, because anyone > can see that. > > You might be able to have the gadget+robot generate some sort of > authentication token, and have the gadget store *that* in the wave, and > use that as your authenticator when the robot receives events saying that > some content has been changed. I haven't thought through this very well > yet, though. The issue of authenticating wave events is IMO a serious > problem that precludes this type of robot, except for personal/experimental > use. > > 6. If somebody besides the wave creator (stored by the robot) tries to edit >> the main wavelet, the robot does not publish the result and resets the >> content to the last published. >> > > I'd argue that it would be *desirable* to allow other participants in the > wave to have the ability to make changes to the content. Consider the case > of a collaborative blog. The ACLs that have been promised as forthcoming in > wave might make this easier to do (allow people to add comments without > allowing them to modify the original document). > > David > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Wave API" group. To post to this group, send email to google-wave-api@googlegroups.com To unsubscribe from this group, send email to google-wave-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=en -~----------~----~----~----~------~----~------~--~---
