Question thread #3

[pauamma]

It's time for another question thread!

The rules:

- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)
- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer.

Comments

[snakeling]

Still working on my script to post Pinboard bookmarks to Dreamwidth. (And much thanks to both you and foxfirefey for your answers last time. I completely forgot to get back at you, my bad entirely. I'll try to be better this time :) )

I'm stuck on, I think, a fairly easy question, that I nevertheless can't find an answer to.

To use the Dreamwidth API (and the Pinboard one), I need the user's password. My script is PHP, and I tell people installing it to do so outside of the public folders, to reduce problems, but even though, I'm not particularly happy at having to store the password, not even encrypted, in the script. Everything I can find about storing passwords securely is about sites that ask you to login, but I do the opposite: I send the password outside. (Unless I'm a dunce and there is a totally different solution I didn't think of.)

I need to store the script on a web server, because the point is for it to run automatically without human input.

Anyone has the beginning of a solution for me?

[pauamma]

Ideally, the directory the password (and script) is in should be outside the Apache document tree (which may be what you mean by "outside the public folders). If that's not possible, you might be able to handle it without a gaping hole by having the password file in a separate directory that also contains a .htaccess that disables directory indexing and that denies HTTP access to all files by requiring authentication and giving an empty list of authentication methods, Thus, the password data will only be readable by locally-running scripts and won't leak out if someone tries to wget the password file by its URL. (This fails if an attacker manages to get their own code running on the server(*), but there's little you can do to protect from that no matter which approach you use.)

(*) If your script lives on a shared server, which is common for PHP, you should make sure that the server operator enforces separation between customers, eg by having a separate Unix account for each virtual domain's directory tree or something along those lines.

[snakeling]

outside the Apache document tree (which may be what you mean by "outside the public folders)
That's indeed what I meant.

you should make sure that the server operator enforces separation between customers
Mine does, and so does the host I recommend, but I'll have to add this to the requirements, then.

Thanks!

[denise]

also, I should add, we have plans to implement OAuth, which will let you authorize an external service to have access to your account, etc. Someday!

Would it work to store the login cookies, instead of the passwords?

[snakeling]

Would it work to store the login cookies, instead of the passwords?
I have no idea! XD I'm using the script as a learning process actually, and I'm making it up as I go along, probably reinventing the wheel a couple of times.

I'm going to keep your suggestion in mind for when I have time to tackle the documentation. Thanks!

[denise]

Reinventing the wheel occasionally leads to advances in wheel technology, so go for it. *g*

[exor674]

If you can bribe someone to help me with the user facing bits... >_> ( also uh, there should totally be a bug for OAuth stuffsies )

[denise]

huh, I thought there was a bug for it. if not, open one!

And hey, if you open the bug, make it needs-design and lay out what the user-facing bits need to do/be/say/etc.

[sophie]

I could use a project to work on, and I know something about OAuth - I've interacted with Twitter's OAuth implementation as a dev, and implemented the client-side bits of it from scratch with no library (which I did so that I knew how it worked; for anything other than local tools, I'd obviously use a library), so... I'm willing to help!

[edit: Which is to say, I implemented it without an OAuth-specific library. I used libraries for URI escaping, URI parsing, HMAC-SHA1 encoding and base64 encoding.]