You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by André Warnier <aw...@ice-sa.com> on 2013/06/29 17:29:27 UTC
Re: [OT] Accessing HREF Target from Servlet
George S. wrote:
> I have a question. I'm doing some oAuth stuff, and the remote site is
> redirecting me to:
>
> my_url.html#something=blah&other_thing=blah-blah
>
> I can see this is the url in the redirect of my browser bar.
>
> What I can't figure out is how to access the part of the URL after the
> pound sign. I've tried getRequestURI(), getPathInfo(), getServletPath(),
> getPathTranslated(), and nothing is working. Also, the elements are
> (correctly) not showing up in the parameters collection.
>
> How can I get that part of the URL from inside a servlet?
>
Hi.
Apart from the answers you already got, and because I am curious :
You seem to say above that this is part of some "Auth" stuff, so I have 2 questions about
that :
1) Why would you need to access that part after the "#" for Auth stuff ?
Intuitively, the part after the "#" is inside of a page. So if access to the page is
already granted/forbidden by the Auth stuff, the part inside of the page should not matter.
2) you also mention (later) that you will be using Javascript to solve the issue.
That means that by the time the Javascript is executed, the page is already in the
browser. From a security point of view, anything that is already in the browser can be
saved by the user, modified, loaded again and submitted to the server.
So is there not a risk here in doing something with Javascript ?
Just being curious, and I can live without the answers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] Accessing HREF Target from Servlet
Posted by Konstantin Preißer <ve...@t-online.de>.
Hi,
> -----Original Message-----
> From: George S. [mailto:georges@mhsoftware.com]
> Sent: Saturday, June 29, 2013 7:45 PM
> To: Tomcat Users List
> Subject: Re: [OT] Accessing HREF Target from Servlet
>
>
> >
> > 1) Why would you need to access that part after the "#" for Auth stuff ?
> > Intuitively, the part after the "#" is inside of a page. So if access
> > to the page is already granted/forbidden by the Auth stuff, the part
> > inside of the page should not matter.
> I'm doing facebook graph api authentication. In the login cycle, you send the
> user to a page facebook page, and you provide that page with a redirect_url.
> After the user does their login through facebook, they get redirected back to
> the url you supplied. In a case of freakish bizarre (for a server-side
> developer), the access token you get is not a parameter on the request.
> IOW, the redirect is to "your_redirect_url.html#access_token=blah", not
> "your_redirect_url.html?access_token=blah". The whole mess is
> documented
> here:
>
> https://developers.facebook.com/docs/facebook-login/login-flow-for-web-
> no-jssdk/
>
> The part about the token being in the URL but not in the query string isn't
> documented there, but it's documented on another page. I'm guessing the
> reason they did this is so that the access_token would not show up in the log
> files of the destination server.
I have also implemented Facebook Login a while ago for a Webapp that runs under Tomcat 7. However, I do not get the fb-code or access_token after a "#" in the redirected url - maybe you used a JavaScript-only variant for the Facebook login?
For example, when doing a Facebook Login, my app does the following:
1. It redirects the user to:
https://www.facebook.com/dialog/oauth?client_id=<client_id>&scope=email&redirect_uri=http%3A%2F%2F<my_redirect_url>
2. After the user logs in, the Facebook site redirects to:
http://<my_redirect_url>?code=<code>#_=_
so the App gets a "code" parameter which is needed to get an access_token.
3. The App can now request an access token by making an HTTP request to a URL like
https://graph.facebook.com/oauth/access_token?client_id=<client_id>&redirect_uri=http%3A%2F%2F<my_redirect_url>&&client_secret=<client_secret>&code=<code>
(using the <code> from the previous redirect, and using the same <my_redirect_url> parameter as on the first redirect to the Facebook site.
4. Then the app can request user information from the Facebook Graph API by making a request to a URL like
https://graph.facebook.com/me?fields=id,name,first_name,last_name,email&access_token=<access_token>.
You can see a live demo here: http://bildergalerie.pleier-it.de/?seite=login (it is a german app for sharing pictures). If you click on the Facebook icon, you will be redirected to FB. After you log in, FB will redirect you to the app with a URL like
http://bildergalerie.pleier-it.de/FBLoginRedirector?code=<code>#_=_
After that, the app will query the user's name from Facebook's Graph API and display it in the top right corner.
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Accessing HREF Target from Servlet
Posted by "George S." <ge...@mhsoftware.com>.
On 6/29/13 9:29 AM, André Warnier wrote:
> George S. wrote:
>> I have a question. I'm doing some oAuth stuff, and the remote site is
>> redirecting me to:
>>
>> my_url.html#something=blah&other_thing=blah-blah
>>
>> I can see this is the url in the redirect of my browser bar.
>>
>> What I can't figure out is how to access the part of the URL after
>> the pound sign. I've tried getRequestURI(), getPathInfo(),
>> getServletPath(), getPathTranslated(), and nothing is working. Also,
>> the elements are (correctly) not showing up in the parameters
>> collection.
>>
>> How can I get that part of the URL from inside a servlet?
>>
>
> Hi.
> Apart from the answers you already got, and because I am curious :
> You seem to say above that this is part of some "Auth" stuff, so I
> have 2 questions about that :
>
> 1) Why would you need to access that part after the "#" for Auth stuff ?
> Intuitively, the part after the "#" is inside of a page. So if access
> to the page is already granted/forbidden by the Auth stuff, the part
> inside of the page should not matter.
I'm doing facebook graph api authentication. In the login cycle, you
send the user to a page facebook page, and you provide that page with a
redirect_url. After the user does their login through facebook, they get
redirected back to the url you supplied. In a case of freakish bizarre
(for a server-side developer), the access token you get is not a
parameter on the request. IOW, the redirect is to
"your_redirect_url.html#access_token=blah", not
"your_redirect_url.html?access_token=blah". The whole mess is documented
here:
https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/
The part about the token being in the URL but not in the query string
isn't documented there, but it's documented on another page. I'm
guessing the reason they did this is so that the access_token would not
show up in the log files of the destination server.
> 2) you also mention (later) that you will be using Javascript to solve
> the issue.
> That means that by the time the Javascript is executed, the page is
> already in the browser. From a security point of view, anything that
> is already in the browser can be saved by the user, modified, loaded
> again and submitted to the server.
The token is an opaque value, that's authorized by the user, so I'm not
concerned about what the user sees. In short, it's their token and they
can't do anything with it that they can't do while logged into facebook.
When my page loads in the redirect, I look for the anchor href and if I
see it, then I set a form field, and submit the form. Tomcat doesn't log
form fields for POSTS, so I don't have the log security issue to worry
about.
> So is there not a risk here in doing something with Javascript ?
>
Security is something I'm trying to really wrap my head around. I've
been given these tokens, which may be long-lived, and the question I'm
trying to come to grips with is how I can prevent them from being
exposed in the event of a server compromise. Also, part of the facebook
app api is an "app secret" that is essentially a key. I also want to
figure out how to keep that from being exposed if the server were
compromised. It's not that I'm paranoid, its just I know people are out
to get me :)
If you've got any really great solutions, I'd be interested. My current
thinking is to create an encryption/decryption service as a bean, and
provide access to it through JNDI. After a server re-start, I would call
a page that would decrypt the private key for the encryption bean. The
next part I need to understand is how to limit access to the bean. IOW,
if joe user pops a JSP page into the server, he should not be able to
gain access to the bean. I'm running Tomcat in a security manager, so I
think I can use that as part of the solution.
Again, any insights are appreciated. I'm really not an expert on the
security manager, or jndi.
> Just being curious, and I can live without the answers.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
George Sexton
MH Software, Inc.
303 438-9585
http://www.mhsoftware.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org