Obsidian Portal API discussion

13»

Comments

  • Shammond42
    Shammond42
    Posts: 65
    Thanks for responding. I have that exact workflow working without any issue in my rails app. I'm confused on the implementation in a command line app. Here is my flow for the authorization step.

    Create consumer with application token and key
    Create an authorization url, print to the terminal and ask the user to paste into broswer
    User pastes the URL into browser and OP generates an access_token and access_secret.
    The user pastes those two values into the console. My understanding is that this is equivalent to requesting the access token, and the token and secret are equivalent to the key and secret I would get from the requested access token.
    I store the token and secret and use them to create an access token with OAuth::AccessToken.new.

    I haven't been able to find examples of desktop and command line apps that use the request_token step, nor can I find a way to use the token and secret in the request_token. Does that make sense? If I understand how to use those values, I'm wondering if maybe the api isn't saving the access token and secret when the page for the user to cut and paste them is shown. OTOH, I seem to remember somebody said they had a command line app working, so maybe I don't understand what to do with the token and secret.

    Thanks,
    Steve
  • Shammond42
    Shammond42
    Posts: 65
    Micah,

    I've done some more research. Here is the clearest twitter command line example I could find (from http://jumpstartlab.com/resources/ruby-jumpstart/jstwitter/).

    def setup_oauth
    consumer = OAuth::Consumer.new(@@credentials[:consumer_key],@@credentials[:consumer_secret], :site => "https://twitter.com")
    request_token = consumer.get_request_token
    Launchy.open(request_token.authorize_url)
    printf "Enter the supplied pin: "
    pin = gets.chomp
    access_token = request_token.get_access_token(:oauth_verifier => pin)
    @@credentials[:oauth_token] = access_token.token
    @@credentials[:oauth_secret] = access_token.secret
    write_settings
    end

    So this code gets a pin from twitter, then does the get access token to get the auth_token and auth_secret. When I use auth_url on Obsidian Portal I (think) I get the token and secret directly. Should I be getting a pin instead somehow so I can use the api to get the token?

    Thanks,
    Steve
  • Shammond42
    Shammond42
    Posts: 65
    I've played with this some more and no success. I think OP needs to return an oauth_verifier rather than the secret/token when I authorize a command line client as above.

    Tonight, I'm going to try to do the authorization as a web client then use the secret and key as a command line tool and see if that works. Any insight is appreciated.
  • Shammond42
    Shammond42
    Posts: 65
    OK, I was able to get this to work, but I had to fake out Obsidian Portal. Here is my authorization code. The important thing to note is that there is nothing on localhost listening on port 8000.

    request_token = Configuration.client.consumer.get_request_token(:oauth_callback => 'http://localhost:8000/respond')
    puts "Put #{request_token.authorize_url} in your browser"

    print "Enter the supplied pin: "
    pin = STDIN.readline.chomp

    access_token = request_token.get_access_token(:oauth_verifier => pin)
    Configuration.auth_token = access_token.token
    Configuration.auth_secret = access_token.secret

    # print "Enter token: "
    # Configuration.auth_token = STDIN.readline.chomp
    # print "Enter secret: "
    # Configuration.auth_secret = STDIN.readline.chomp

    Configuration.save!

    So, when I paste the url into my browser, I go to OP and authorize. Instead of seeing the page with the token and secret I am redirected to localhost:8000 which fails. I can then grab the oauth_verifier from the requested url, and paste than into my command line app as the "pin". The app can then request and access_token, get the token and secret, and everything works.

    So, upshot, I think there's an issue with the OP after authorization. It should redirect me to a page with the oauth_verifier instead of the token and secret.

    Hop this helps,
    Steve
  • MishieMoo
    MishieMoo
    Posts: 2
    Micah,

    I too am having issues with getting the tokens, but that's because I am writing an Objective-C wrapper, and frankly, the entire token doesn't even fit on the screen!

    Yes, while the token is sent via the url, the verifier/secret is not. And as you can't view-source in an iPhone, I cannot figure out any easy way to automatically pull in the verifier, as copying is just a very bad idea on a small screen (especially when the website isn't mobile friendly!). So that brings me to my two questions.

    Firstly, is there any way I can get my hands on the html source code of that authorization page? There's some js goodness that can grab out the verifier instead of having the user manually copy and paste (better user experience). While I can resort to copy/paste, I would rather not as that complicates quite a few things.

    Secondly, what would it take to get a mobile-friendly layout for this page? I am planning on making an app using this wrapper, once it's finished, and, well, the way it is now is not friendly at all. A user wants to read the instructions on the page, and having to scroll horizontally to do so is a problem. I'll even offer to help if needed. I've worked on quite a few mobile websites.

    Thanks in advance!
    Michele
  • Micah
    Micah
    Posts: 894
    Hey Folks,

    I've been distracted for a bit, but Ryan has been doing a review of the API. We've got a few smal changes coming, and I'll look into the issues with the OAuth tokens and such. Just wanted to say we're still here, just really really busy!
  • Micah
    Micah
    Posts: 894 edited February 2011
    Steve & Michele - I'm going to work on the OAuth mobile workflow and page tonight (and possibly into the next week). I'll see about thing in this order:

    # Showing the correct data (the verifier, not the token/secret).
    # Making the page a little more mobile friendly in terms of layout.
    # Seeing what it would take to enable a better mobile experience, like auto copy-paste or the auto-return stuff that's possible with some Twitter clients.

    Sorry it took so long.
    Post edited by Micah on
  • Micah
    Micah
    Posts: 894 edited February 2011
    I'm pushing an update tonight with a few changes. It should hopefully make the authorization success page a little friendlier to users.

    It also puts the verifier in an easily-parsible HTML element. Just look for a code element with the id of "oauth-verifier" like so:

    abc123

    So, if you're running an embedded browser that allows you to run javascript or interact with the DOM, you should be able to automatically extract the verifier.
    Post edited by Micah on
  • Micah
    Micah
    Posts: 894
    We are on the cusp of "releasing" the API. Essentially, for those of you who have been working with it, it means very little. However, there are a few salient points:

    * We will be sticking with OAuth. While not perfect, it offers the best balance of ease and utility to both developers and end users.
    * We will not be changing any endpoint URLs, either for the OAuth workflow or for the API itself (note: we may yet make a small change to one of the OAuth URLs, but we'll give plenty of warning)
    * We will not be adding any *required* parameters to endpoint URLs
    * We *will* be adding new optional parameters
    * We will not be *removing* any fields from returned data
    * We *will* be adding new fields (and new API endpoints).
    * Any change that involves adding a required parameter, removing a field, or changing an endpoint will result in a version change to the API. We'll always give plenty of warning and time to switch, unless it's a gaping security issue.

    Basically, once we say it's ready, we're locking things down and not making any big changes. This is to make it easier on you, the developers, so you don't have to constantly keep updating your applications in order to track a moving target.

    If there's anything you absolutely hate about the API right now, or something you desperately want changed, please let us know. There's still a little time. No guarantees that we can do everything you want, but it's better if we know.

    And remember: We will be adding more functionality to the API (like adding items, maps, and forum posts), so don't worry about that. We just want to know if there's anything about the underlying structure (request format, parameters, data returned) that you don't like. We added the mini-objects as a result of user feedback, and we're hoping you have more good ideas like that.
  • Shammond42
    Shammond42
    Posts: 65
    MIcah,

    You strategy seems sound. I will give my app a try today with the improved workflow and let you know how that goes.

    Steve
  • MishieMoo
    MishieMoo
    Posts: 2
    Hey Micah,

    Thanks for adding that! It'll make life so much easier for mobile users to not have to copy/paste. I'll play with it when I'm home later, for sure!

    I haven't had any trouble with the API so far, but I haven't really started digging deep yet. My main problem so far is that none of the responses are actually "valid json.":http://www.jsonlint.com/ It's not the total end of the world, as most parsers out there won't completely break, but I have noticed a few stray commas on the last item in an object and such like that which really isn't good (see "character index(list)":http://help.obsidianportal.com/kb/api/api-characters campaign mini-objects). I haven't gotten to parsing out much yet, as OAuth is a real pain for iOS, but hopefully I'll be able to get the basic requests working within the next day or two to make sure that it's all working well together (which it should, as no one else has had a problem yet).

    Thanks for the update!

    Michele
  • Micah
    Micah
    Posts: 894
    Michele,

    Invalid JSON is a big no-no. Thanks for pointing it out and I'll definitely take a look. We have tests to parse the JSON output, but perhaps they're lenient as you say. I'll see if I can put rework the tests to put them in strict compliance mode so as to make sure everything is 100% valid.
  • Micah
    Micah
    Posts: 894
    Ah, I think I may see now. There are some typos in the documentation, but I doubt those exist in the actual output from the API. I had to hand-create some of the examples in the documentation, and there could be typos.

    I'll double-check to be sure, but if you haven't seen any invalid JSON actually come back from the API, then it's probably just a typo in the docs.
  • Micah
    Micah
    Posts: 894
    Going to make a small change with campaign latitude/longitude. It will be in a JSON object called "location" as such:

    'location' : {
    'lat' : 123,
    'lng' : 99
    }

    We're doing this because we might want to add more location info in the future, and it seems like a good thing to break into a sub object.
  • gunan
    gunan
    Posts: 1
    Hi,
    I work on a small tool to import dnd4e files. The OAuth authentification works fine and I am able to retrieve character/campaign data. When I try to create a new character I get a 400 : Invalid JSON syntax. The json data for testing ist here http://jsonlint.com/ validated. I even tried the request body from the knowledge base example:

    {"character":{"name":"BBEG","tagline":"Awaitinginhisfortress","description":"Level30wizard","bio":"Darklordofdestruction,watchingfromonhigh","game_master_info":"Actuallyquitecuddly","is_game_master_only":true,"dynamic_sheet_template_id":"0343472200f011e0b2b340403656340d","dynamic_sheet":{"race":"Drow","class":"Wizard","level":"30"}}}


    Any ideas or working json data?
Sign In or Register to comment.

March 2024
Wrath of the Highborn

Read the feature post on the blog
Return to Obsidian Portal

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Discussions