Vanilla 1.2.1 is a product of Lussumo. More Information: Documentation, Community Support.
1 to 16 of 16
I put up a blog post with some ideas about how to use the API to make DST creation and editing much easier. It’s by no means the one and only way to approach it, just my first thoughts.
I’d love for someone to step up and create an actual desktop application to handle this. If you’re interested, please speak up and let’s figure out a way to make this happen.
This is a great idea, and could potentially be taken one step further with an option that watches the files and updates automatically when you save them. I might take a crack at this myself in fact, although I’ve never written a desktop application that address a web API like this. Shouldn’t be too tough.
I agree about not reinventing the wheel. I don’t want a new text editor. Instead, the app just knows the paths to your text files on disk. You use your favorite text editor to edit them normally. When you want to see how it looks, you click a button in the app to sync it to the server, then refresh a test character that’s live on the site. Alternately, it could auto-sync every time you save a file, although that might be a little rough on the API.
This is just one idea, and I’m definitely open to others. I would like, however, to remove the dev kit as much as possible. It’s going to get out of date, I just know it.
Hitting the API every 30s is fine. Things might get hairy if you’re hitting it every 5s, but 30s should be no problem.
Also, the main sticking point here (that I can see) is how to do OAuth in a desktop application. Does every person who downloads it need to create their own OP app in order to get a client key and secret? Or does every instance of the desktop app use the same key/secret, which means anyone can steal it and make requests cloaked as that application?
Doing a little searching shows that OAuth is not so great with desktop / mobile apps. See more here: http://stackoverflow.com/questions/1934187/oauth-secrets-in-mobile-apps
Hmm, that really sucks, as I imagine that a lot of the API apps will be mobile or desktop apps. Crap, gonna have to rethink things a bit…
I’ve skimmed over the OAuth documentation, and it honestly doesn’t seem like its worth the effort for desktop and mobile apps. Requiring you to embed a browser in your application – because, of course, having the user enter their credentials through the application itself defeats the whole point – is a pretty significant burden to place on application authors. And of course it’s done in the name of protecting users from applications they don’t trust, while not asking the obvious question: if you don’t trust the application, why are you using it?
At some point in the process, inevitably, someone has to trust someone. In this case, either users have to trust application developers not to steal their credentials, or application developers have to trust anonymous malicious hackers not to decompile their code and impersonate their applications. The hackers may represent the less common threat, but on the whole, I think the application developers are the more trustworthy bunch there, and doing simple authentication through the application has the added advantage of being, as the name implies, simple.
We’re trying to come up with a good-enough solution, even if it’s not perfect. Someone described OAuth as a “bad solution to a horrible problem” and I think it’s a pretty good description. It’s not great, but it’s better than something I could come up with on my own.
I’ll grant that it’s not perfect for mobile and desktop apps. There will never be a way for us to verify that they are who they say they are. Someone can grab their key and secret and use that to make requests in the name of the app it was stolen from. The OAuth people recommend not trusting the consumer key and secret and using it only for statistics gathering. That’s our plan. We won’t go around invalidating keys in order to stop hackers. We’ll have to be smarter than that.
On the upside, even if we cannot trust the application to be who it says it is, OAuth still allows us to protect the users. An app with a stolen key and secret would still need to get the user’s access token and secret in order to make requests on their behalf. Likewise, a user can decide to revoke access to an application at any time, and they can revoke selectively. With most simple schemes, like an API key, the user would have to revoke access to all apps, and still has the copy/paste issues of OAuth. Worse still, if they used username/password, they would have to change their password if they ever wanted to revoke access to an app.
For now we’re going to push forward with OAuth, but this is the kind of feedback that we want. There’s still time to switch to something else, and if everyone truly hates it, we’ll definitely listen.
That seems reasonable to me. The only question in my mind is how you plan to implement the interface involved. From your description, it sounds like you’re planning an authorization front end, where users can generate one-off credentials and manually copy them to a given client. A bit cumbersome, but certainly less of a burden on application developers. Am I understanding correctly?
Currently, it would work like this:
Web apps – Normal OAuth flow. Redirect users to our OAuth authorize page, when they accept, they’re redirected back to the web app along with their credentials.
Mobile / Desktop app – Embed your consumer key/secret in the app, knowing it could be stolen and used to impersonate your app in our statistics. Oh well. App generates the OAuth authorize URL and displays it to user saying “copy this to your browser” or, if the platform allows, open the default browser and point it to the authorize URL. User logs in, authorizes the app, and is shown their authorization verifier (we’ll need a better name). Copy and paste that into the app and it has everything it needs to get an access token.
Summary: For web apps, user does nothing except login and click authorize. For desktop/mobile, they have the extra steps of going to the browser, then copying and pasting the verifier that’s displayed. Not great, but it seems to work for Twitter.
I have read some interesting ideas about desktop apps asking for username/password then exchanging that for an access token. They still use OAuth for all API calls, but bypass the entire authorize workflow and instead just ask the user for username/password. It’s definitely a better user experience, but I really dislike training users to give out username/password. I think it’s a bad habit all around, and users should be suspicious when any app asks for that.
Yeah, that’s pretty much what I expected Micah. Thanks for spelling it all out. Providing the user name and password to the application is a lot simpler for the user, but at that point you might as well skip OAuth entirely, as the application could easily capture the user’s information. The price we pay for security is, as usual, mild inconvenience.
Somewhat related to this discussion:
I’m adding the dynamic sheet data to the Characters API methods. That means it will be possible to build things like an importer for .dnd4e files or PCGen exports.
The dynamic sheet data is a little trickier to work with, and you risk wiping out someone’s character in a heartbeat, so be careful!