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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
George Sexton
MH Software, Inc.
303 438-9585
http://www.mhsoftware.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
