Announcement Announcement Module
No announcement yet.
Problem on redirect_uri address Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem on redirect_uri address


    I am having problem url redirect address after a successful authorization.
    The redirect address has # instead of ?

    Is this a bug in
    http://localhost:8080/oauth/authorize?response_type=token&client_id=900c3eab9c d06fea&scope=read&redirect_uri=http://localhost:8080/api/photos


    If I change # to ? then the url works fine.

  • #2
    It looks like you're getting what you asked for there - if you ask for response_type=token you get a fragment encoded token. Look up "Implicit Grant Type" in the spec.


    • #3
      Are you saying I asked for http://localhost:8080/api/photos#access_token?

      Why it isn't ? in the uri?


      • #4
        Originally posted by shahbazi View Post
        Why it isn't ? in the uri?
        Why should it be? Did you read the spec on implicit grants? Is that not what you need? Please try to explain a bit more what you expect to happen and why.


        • #5
          I am not sure, but I am think there is bug in line 53
          of OAuth2AuthenticationProcessingFilter request.getParameter(OAuth2AccessToken.ACCESS_TOKE N)
          can not read the access token from request while it come as #access_token

          Yes, I am reading the spec I don't know why we are using #

          The problem is, when I use
          It always goes to the Authorization Server's access confirm page. As soon as I change it to ?access_token=... then works perfectly.

          I've similar problem to this guy:
          Last edited by shahbazi; Mar 3rd, 2012, 06:59 PM.


          • #6
            Originally posted by shahbazi View Post
            Yes, I am reading the spec I don't know why we are using #
            Because that's what it says in the spec A URI fragment (after the #) is not passed on to the server by a browser client - that's intentional, and it's a feature exploited by the spec to prevent access tokens from being exposed in server logs etc. If your client is not able to consume the fragment, then you need a new client, or a new grant type.