Hoodie Social Support about discussion

[gr2m]

sorry we couldn't look into it, we have so much stuff to do, working towards the 1.0 release. But it's great to see that you're moving on with it!

On 24 Jan 2014 at 23:16:15, inator ([email protected]) wrote:

Continuing the discussion and providing updates as referenced:

hoodiehq/hoodie-server#169

I pushed an update to the social plugin to support Pocket configuration (not tested with the new Pocket yet):

inator/hoodie-plugin-social@28870a4

I'm getting ready to start work on support for social posting, so if any of you have any feedback on what's been done so far, please be sure to let me know. Thanks!

—
Reply to this email directly or view it on GitHub.

[inator]

Accidental close. reopened.

[inator]

I just published v0.5.0 which adds the ability to connect to social accounts and perform a social post.

[janl]

@inator I finally had a chance to look at things. Great job getting this all together!

I didn’t quite get how you deal with CouchDB user passwords and the tmp_pass business. Are there docs on that?

You are doing business with opening a full new server on another port, I assume this is because Hoodie plugins can’t extend Hoodie’s _api/ URL space, correct?

[janl]

And why are you using the CouchDB proxy feature?

[inator]

@janl - Thanks so much for taking the time to have a look!

Beyond the Readme, there's not any docs yet on the "temp_pass" process, so let me explain. One of two things happen with each social login request (see this); 1) a new user is created using a randomly generated password, or 2) an existing user is identified and their password is updated with a new randomly generated password. Then this password is passed to the front end in a one-time transaction, where the plugin invokes a standard hoodie.account.signIn(). Every social login request restarts this process.

Admittedly, the "temp_pass" label is a bit of a misnomer, since I couldn't implement the original vision of passing a true temp password, then immediately change it on the backend. Unfortunately, as I'm sure you know, this would break the active session.

While this process works quite well (assuming SSL use) and has the benefit of eliminating any major front end changes (it uses the standard hoodie login), I believe a better approach would be to eventually use some sort of CouchDB oAuth and just pass around tokens instead. This of course will require some hoodie core front end changes.

In regards to opening a new full server, yes, I couldn't devise a method to extend the existing server using the plugin architecture, and much of the decision resulted from the need to deal with the browser based Auth hand-off and callback loop with providers.

Why is this all exposed via the CouchDB proxy feature? It was a quick and dirty way to allow the front end to be standardized without some sort of initialization to communicate which custom port to talk to the Social Auth server through. If it proves problematic, or if you have another solution in mind, we could certainly revisit that.

Finally, please know that I am very interested in your ideas for moving this forward. Over the past week I've added additional features to start to round out the plugin to become a true social component. Although I still need to spend some time optimizing the code (streamlining into common functions and such), it's quite functional now - but also based on what started as a rough proof of concept.

Thanks again Jan!

[inator]

One more note - I have yet test this with the latest version of Hoodie. I'm assuming there might be an issue here to there, but hopefully nothing major.