I think the best would be to e-mail the mods at [email protected] with this question

done - but it's also a more generic question for other sites. I remember when (maybe they still do) sites like facebook would ask for email name and password and then login to your email to get address of people to invite. I just moved to Dynalist from Workflowy and they have a option to import your workflowy data - you give your login username/password and it does it for you. etc.

I'm interested in it for hackernews - but I'm also interested if there are other guidelines/rules/examples for this kind of process in general.

A simple workaround is to use login client-side, and not your server. That way, you store the cookie on the client, and use it for HN actions, without having to be a centralized place of all user info.

Many HN reader apps implement this as well.

I don't understand how this would work.. Can you give an example of a reader that does this?

The news.ycombinator.com site for one -- saves login on browser via cookie. HN reader android app also does this.

This is the site with the credentials - It's not an intermediary/proxy.

The point is I want to have a different site (eg. myawesomehnsite.com) that will use the firebase api for a reader but allow the user to upvote or comment on my site and proxy that action to news.ycombinator.com. Unless they expose some API to do it, which AFAIK they don't, you don't have a way to do this entirely in the browser. You'll hit cross-site XHR issues or the requests will not be authorized (look at the link for an upvote - it has an auth qs var - this is custom per user per link).

There's non CORS issue if you control the client (an app). The login POST call on news.ycombinator.com is the API you need.

If you want it as a website/in the browser, then you can make an extension instead of an app (going to yoursite.com should request installing extension, or load the site if extension is present).

There are readers that can do that. Minihack as example.

thanks for the example - means people are doing it.

With a mobile app - it is different I guess in that the credentials are probably staying on the mobile device - they just need to do the proxying on the client - it seems.

I don't have an Iphone to test - if someone has Charles or some other proxy to see where the requests are going, I'd be interested to hear.

Sounds fraught with spam risk

It is - it's really based on trust. The truth is anytime you give any credentials to anyone, they can abuse it (to the extent the credentials allow.)

For services that don't have something like OAuth to give a token-based credential that is limited in scope/time, the only option is to give full access via username/password. The biggest risk here would be if the other site were to not only spam using the user's account, but hijack it completely changing the password or even the email account. With a token-based authorization, you can always revoke the token and never expose the authentication of the account.

But since the value of a hijacked hackernews account is relatively low, it seems to me people might be more likely to trust such a process (assuming it added value.) If it was malicious, it would be discovered relatively quickly and the ruse would be over, with little to nothing gained for the effort.