tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George S." <>
Subject Re: [OT] Accessing HREF Target from Servlet
Date Sat, 29 Jun 2013 17:44:32 GMT

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 

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 

> 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:
> For additional commands, e-mail:

George Sexton
MH Software, Inc.
303 438-9585

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message