Not signed in (Sign In or Register)

Discussion Tag Cloud

Vanilla 1.2.1 is a product of Lussumo. More Information: Documentation, Community Support.

    • CommentTimeDec 8th 2010

    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.

    Some references:

    That's a very interesting idea. Definitely, a better way to create DSTs would be a big help, I think. The current dev kit is a little hard to get into, though once you get the idea, it works just fine.

    C# is my specialty, so I would be speaking from this reference. Probably what I'd do is let people use their own editors to edit the HTML template/CSS/Javascript... no need to reinvent the wheel there... just have a hosted browser window that watches for updates to those files and refreshes it's view... where the view is the dev kit's wrapper HTML with the CSS and template from the user injected into it.... probably have spots for the user to enter the slug etc so the template will work.

    Then it's just a matter of a simple UI for downloading / uploading the files via the API, which shouldn't be too hard. I think, by keeping it simple, it can be pretty robust and easy to use. Get fancy, and things get buggy and take a lot longer to build.

    I would imagine this is doable in a weekend or a few weeknights for someone with some free time (something I am notably lacking... though I may give it a try anyway... been wanting to poke at the API some to get some ideas about how it might be used).

    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.

    • CommentTimeDec 8th 2010

    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.

    Ahh, I wasn't sure how much you'd want people saving in-development copies of the DST to the site. When developing my DST, I tend to change one CSS property, save, reload the sheet. That process can result in a save every 30 seconds or so. If it's cool to save that often to the site, then I think using the site as the display is actually a great idea.. .then there's no chance of the development display being different from the production display.
    • CommentTimeDec 8th 2010

    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, there is no issue with having in-development html, css, or javascript in the DST. That’s what the review process is for. Having the in-development code live on the site allows you to see exactly what it will look like for a character, which is really the end goal anyway.

    • CommentTimeDec 8th 2010 edited

    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:

    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…

    • CommentTimeDec 9th 2010 edited

    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.

    • CommentTimeDec 9th 2010

    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?

    • CommentTimeDec 9th 2010

    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.

    So, read up on OAuth.

    In order to really protect users, you'd need something like the banks where they give you an authentication image that you choose when you create your account, that's only stored on OP's servers, so you know it's really OP that you're logging into... otherwise the hosted browser could just send you to a fake site to steal your password. This still requires the desktop app to host a browser that sends you to the website, and retrieves the access token... but that seems like something that could be written once and reused. (this assumes an embedded browser in the desktop app, so you can't trust the URL/web page it shows you is really yours, without secret info from the site).

    Without that, you'd need to have the users do what Chainsaw is talking about, and log into the site using a normal browser (in which we trust the URL will tell us when we're really connected to OP), and then get an access token from there to give to the desktop app.

    The first one is more work, and the second one is just not a viable user experience, I think.

    It's an interesting problem, for sure.
    Ahh, you commented while I was writing... launching the external browser works like my option 2. Not a very good user experience.... but secure, at least.

    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.

    If we're talking about a simple filesystem monitor, there doesn't necessarily need to be much of a front-end to that. Only the configuration UI; that's it. Even that could be simplified down to a .ini, .conf, .properties file if need be.
    • CommentTimeDec 19th 2010

    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!