RSVP BTN Authentication and Security protocols

[Ryan Flannagan]

We are currently playing with the RSVP button for our Wordpress Meetup
plugin, but Meetup's authentication and security protocols are making
it difficult. Basically, to add a RSVP button to your site, it's
really easy. You just enter an event ID and the site where you want
to add it. Meetup then generates a script url to personalized
javascript file. This ensures that that particular javascript only
runs from the site url you specified in advance.

The problem for us is that we don't know that the site url is going to
be--which means end users would have to 1) go to that form and
generate their own secure script url for their site, 2) copy that
script url into an options page on the plugin's admin interface.
That's a bit annoying, but certainly doable.

Is there anyway to get around this? Such as an API for generating
those custom secure script IDs

[Doug Tangren]

The way this works under the covers is by using oauth2 protocol and the implicit browser flow for authorization.
Part of that protocol is a requirement for having pre-registered an oauth client's redirect_uri for authorization. The idea is to have this registered prior to its use in requesting member authorization so that the server has a validated uri for which to redirect the member to after they submit their authorization response.

In the case of the RSVP button, when we prompt for a website name and address, we are really asking for an oauth consumer name and redirect_uri to use for oauth client registration. The id that gets appended to the mu.btns.js script is the client id of the registered oauth client. The redirect uri is implicitly the page that the user installs the button on, so when a request for authorization is made we use that to compare with the website address that was pre-registered.

OAuth clients are associated with the a member on the site. This is why we do the form-based registration on the site. If we were to expose an oauth consumer create api, the consumers would be associated with the member making the call, this would be you and not the user providing the name and web address. This would create a problem in terms of managing that consumer. You can manage and edit oauth consumer information you own on the site. This would then include oauth consumers created through you as a proxy, which actually probably should be owned and managed by the person that provided you the information. Since this is the case, such an api would have to be enabled oauth through oauthed requests on behave of the person registering a consumer through the api.

[Sond...@aol.com]

i never saw so much conversation about something and i still dont know what to do with it!!

[Doug Tangren]

On Wed, Nov 30, 2011 at 11:43 AM, <Sond...@aol.com> wrote:

i never saw so much conversation about something and i still dont know what to do with it!!

The idea behind http://www.meetup.com/meetup_api/buttons/ is to make the concept of oauth transparent to members while making it easy to register what is needed for the protocol.

[Ryan Flannagan]

Thanks for the explanation. We will thing about how we will use this
going forward.

Ryan

On Nov 30, 10:17 am, Doug Tangren <d...@meetup.com> wrote:
> On Wed, Nov 30, 2011 at 11:43 AM, <Sondra...@aol.com> wrote:
> > **

> > i never saw so much conversation about something and i still dont know
> > what to do with it!!
>

> The idea behindhttp://www.meetup.com/meetup_api/buttons/is to make the