The official php client includes a Facebook object (and a
FacebookDesktop object as well). This object uses FacebookRestClient,
but it also exposes a wealth of useful functionality which is sorely
missing from the current Java client.
I am writing a feature-by-feature Java implementation of this object,
and I would like to know if there is any interest by the developers
and users of this group to include it in the next version of this
project. Including this object will not break the drop-in
compatibility, of course.
Features provided by this object:
1) Verifying that the various fb_sig_ parameters are authentic, using
md5 hashing with the app's secret key. I think this is an important
security feature. Facebook expects apps to do this, and with the php
client it happens automatically.
2) Easy to use methods for login and authentication.
Facebook.require_login() to force login, Facebook.require_add() to
force the user to add the application, Facebook.require_frame() to
force the app to be inside a facebook frame (as opposed to a stand-
alone webapp).
3) The above mentioned methods use a smart redirect feature. It emits
an fmbl redirect code if the page is in a canvas, or sends a "frame-
bypassing" redirect if using an iframe (so you don't nest duplicate
facebook navigation bars), or simply sends a redirect if the app is a
stand-alone webapp).
3) Additional useful methods, such as Facebook.is_fb_canvas(),
Facebook.is_frame() to determine if the app is in a frame or canvas.
4) Fall-back to using cookies for authentication if the fb_sig_ params
are not present (I haven't implemented this yet).
Please let me know if this would be useful for this project.
Thanks,
Yoni
I'd be interested, sounds like some useful utility methods. 1 is already implemented in FacebookSignatureUtils, but a wrapper that does it automatically sounds like a nice idea.
Travis
On Jan 1, 2008 12:39 PM, Yoni <amir.y...@gmail.com> wrote:
> The official php client includes a Facebook object (and a > FacebookDesktop object as well). This object uses FacebookRestClient, > but it also exposes a wealth of useful functionality which is sorely > missing from the current Java client. > I am writing a feature-by-feature Java implementation of this object, > and I would like to know if there is any interest by the developers > and users of this group to include it in the next version of this > project. Including this object will not break the drop-in > compatibility, of course.
> Features provided by this object:
> 1) Verifying that the various fb_sig_ parameters are authentic, using > md5 hashing with the app's secret key. I think this is an important > security feature. Facebook expects apps to do this, and with the php > client it happens automatically.
> 2) Easy to use methods for login and authentication. > Facebook.require_login() to force login, Facebook.require_add() to > force the user to add the application, Facebook.require_frame() to > force the app to be inside a facebook frame (as opposed to a stand- > alone webapp).
> 3) The above mentioned methods use a smart redirect feature. It emits > an fmbl redirect code if the page is in a canvas, or sends a "frame- > bypassing" redirect if using an iframe (so you don't nest duplicate > facebook navigation bars), or simply sends a redirect if the app is a > stand-alone webapp).
> 3) Additional useful methods, such as Facebook.is_fb_canvas(), > Facebook.is_frame() to determine if the app is in a frame or canvas.
> 4) Fall-back to using cookies for authentication if the fb_sig_ params > are not present (I haven't implemented this yet).
> Please let me know if this would be useful for this project. > Thanks, > Yoni
I'm implementing 1) because I didn't see FacebookSignatureUtils and part of 2/3) in my own servlet filter code, but I second Travis, it'd be interesting if your code could be added here.
> I'd be interested, sounds like some useful utility methods. 1 is already > implemented in FacebookSignatureUtils, but a wrapper that does it > automatically sounds like a nice idea.
> Travis
> On Jan 1, 2008 12:39 PM, Yoni <amir.y...@gmail.com> wrote:
> > The official php client includes a Facebook object (and a > > FacebookDesktop object as well). This object uses FacebookRestClient, > > but it also exposes a wealth of useful functionality which is sorely > > missing from the current Java client. > > I am writing a feature-by-feature Java implementation of this object, > > and I would like to know if there is any interest by the developers > > and users of this group to include it in the next version of this > > project. Including this object will not break the drop-in > > compatibility, of course.
> > Features provided by this object:
> > 1) Verifying that the various fb_sig_ parameters are authentic, using > > md5 hashing with the app's secret key. I think this is an important > > security feature. Facebook expects apps to do this, and with the php > > client it happens automatically.
> > 2) Easy to use methods for login and authentication. > > Facebook.require_login() to force login, Facebook.require_add () to > > force the user to add the application, Facebook.require_frame() to > > force the app to be inside a facebook frame (as opposed to a stand- > > alone webapp).
> > 3) The above mentioned methods use a smart redirect feature. It emits > > an fmbl redirect code if the page is in a canvas, or sends a "frame- > > bypassing" redirect if using an iframe (so you don't nest duplicate > > facebook navigation bars), or simply sends a redirect if the app is a > > stand-alone webapp).
> > 3) Additional useful methods, such as Facebook.is_fb_canvas(), > > Facebook.is_frame() to determine if the app is in a frame or canvas.
> > 4) Fall-back to using cookies for authentication if the fb_sig_ params > > are not present (I haven't implemented this yet).
> > Please let me know if this would be useful for this project. > > Thanks, > > Yoni
Travis, thanks for the tip. I didn't know about
FacebookSignatureUtils. My code is very similar, and in fact by
looking at FacebookSignatureUtils I figured out how to use the md5
digest.
Laurent, I contacted aroth, so I hope that the code will be integrated
soon.
On Jan 2, 3:06 pm, "Laurent Perez" <hak...@gmail.com> wrote:
> I'm implementing 1) because I didn't see FacebookSignatureUtils and
> part of 2/3) in my own servlet filter code, but I second Travis, it'd
> be interesting if your code could be added here.
> > I'd be interested, sounds like some useful utility methods. 1 is already
> > implemented in FacebookSignatureUtils, but a wrapper that does it
> > automatically sounds like a nice idea.
> > Travis
> > On Jan 1, 2008 12:39 PM, Yoni <amir.y...@gmail.com> wrote:
> > > The official php client includes a Facebook object (and a
> > > FacebookDesktop object as well). This object uses FacebookRestClient,
> > > but it also exposes a wealth of useful functionality which is sorely
> > > missing from the current Java client.
> > > I am writing a feature-by-feature Java implementation of this object,
> > > and I would like to know if there is any interest by the developers
> > > and users of this group to include it in the next version of this
> > > project. Including this object will not break the drop-in
> > > compatibility, of course.
> > > Features provided by this object:
> > > 1) Verifying that the various fb_sig_ parameters are authentic, using
> > > md5 hashing with the app's secret key. I think this is an important
> > > security feature. Facebook expects apps to do this, and with the php
> > > client it happens automatically.
> > > 2) Easy to use methods for login and authentication.
> > > Facebook.require_login() to force login, Facebook.require_add () to
> > > force the user to add the application, Facebook.require_frame() to
> > > force the app to be inside a facebook frame (as opposed to a stand-
> > > alone webapp).
> > > 3) The above mentioned methods use a smart redirect feature. It emits
> > > an fmbl redirect code if the page is in a canvas, or sends a "frame-
> > > bypassing" redirect if using an iframe (so you don't nest duplicate
> > > facebook navigation bars), or simply sends a redirect if the app is a
> > > stand-alone webapp).
> > > 3) Additional useful methods, such as Facebook.is_fb_canvas(),
> > > Facebook.is_frame() to determine if the app is in a frame or canvas.
> > > 4) Fall-back to using cookies for authentication if the fb_sig_ params
> > > are not present (I haven't implemented this yet).
> > > Please let me know if this would be useful for this project.
> > > Thanks,
> > > Yoni
Yes, sounds very useful. I sent you an e-mail with instructions for
how to enable SVN commit access. If you prefer, you can send the
changes directly to me, and I'll commit them.
On Jan 5, 3:06 am, Yoni <amir.y...@gmail.com> wrote:
> Travis, thanks for the tip. I didn't know about
> FacebookSignatureUtils. My code is very similar, and in fact by
> looking at FacebookSignatureUtils I figured out how to use the md5
> digest.
> Laurent, I contacted aroth, so I hope that the code will be integrated
> soon.
> On Jan 2, 3:06 pm, "Laurent Perez" <hak...@gmail.com> wrote:
> > I'm implementing 1) because I didn't see FacebookSignatureUtils and
> > part of 2/3) in my own servlet filter code, but I second Travis, it'd
> > be interesting if your code could be added here.
> > > I'd be interested, sounds like some useful utility methods. 1 is already
> > > implemented in FacebookSignatureUtils, but a wrapper that does it
> > > automatically sounds like a nice idea.
> > > Travis
> > > On Jan 1, 2008 12:39 PM, Yoni <amir.y...@gmail.com> wrote:
> > > > The official php client includes a Facebook object (and a
> > > > FacebookDesktop object as well). This object uses FacebookRestClient,
> > > > but it also exposes a wealth of useful functionality which is sorely
> > > > missing from the current Java client.
> > > > I am writing a feature-by-feature Java implementation of this object,
> > > > and I would like to know if there is any interest by the developers
> > > > and users of this group to include it in the next version of this
> > > > project. Including this object will not break the drop-in
> > > > compatibility, of course.
> > > > Features provided by this object:
> > > > 1) Verifying that the various fb_sig_ parameters are authentic, using
> > > > md5 hashing with the app's secret key. I think this is an important
> > > > security feature. Facebook expects apps to do this, and with the php
> > > > client it happens automatically.
> > > > 2) Easy to use methods for login and authentication.
> > > > Facebook.require_login() to force login, Facebook.require_add () to
> > > > force the user to add the application, Facebook.require_frame() to
> > > > force the app to be inside a facebook frame (as opposed to a stand-
> > > > alone webapp).
> > > > 3) The above mentioned methods use a smart redirect feature. It emits
> > > > an fmbl redirect code if the page is in a canvas, or sends a "frame-
> > > > bypassing" redirect if using an iframe (so you don't nest duplicate
> > > > facebook navigation bars), or simply sends a redirect if the app is a
> > > > stand-alone webapp).
> > > > 3) Additional useful methods, such as Facebook.is_fb_canvas(),
> > > > Facebook.is_frame() to determine if the app is in a frame or canvas.
> > > > 4) Fall-back to using cookies for authentication if the fb_sig_ params
> > > > are not present (I haven't implemented this yet).
> > > > Please let me know if this would be useful for this project.
> > > > Thanks,
> > > > Yoni
The code is now committed. Here's how my servlet filter looks like:
public void doFilter(final ServletRequest request, final
ServletResponse response, FilterChain chain) throws IOException,
ServletException {
HttpServletRequest httpReq = (HttpServletRequest) request;
HttpServletResponse httpRes = (HttpServletResponse) response;
HttpSession session = httpReq.getSession();
Facebook fb = new Facebook (httpReq, httpRes,_apiKey, _secretKey);
String next = httpReq.getServletPath().substring(1);
if (fb.requireLogin(next)) return;
session.setAttribute(ServerUtils.FACEBOOK_CLIENT,
fb.getFacebookRestClient());
chain.doFilter(request, response);
}
As you can see, the Facebook object is not designed to be kept in the
server-side session. You need to create a new one and then discard it
with every request that comes. It associates itself with a request-
response pair so it can issue a redirect properly if necessary. This
is not to my particular taste, and I know it can be done differently,
but I copied the object from the php library almost line-by-line, and
it was important for me to preserve the same semantics (albeit with
some exception to adapt the code for Java specific features).
I'm using an iframe for my application, not fbml, so I only had a
chance to test this in a stand-alone webapp (accessing it locally at
http://localhost:8080/myapp/) and inside facebook via an iframe.
In both cases the method requireLogin does what it is supposed to do.
It returns a boolean flag indicating whether or not a redirect to
Facebook's "login to this app" page was issued.
My application happens to also have a servlet that is serving ajax
requests. It requires access to FacebookRestClient, so I keep it in
the session. As you can see, it happens to be that this object in the
session gets overwritten with every request. I think this is not the
ideal design, but I doubt if this is a big deal, unless you are facing
serious performance issues.
The magic is of course in the constructor. It does the following:
1) Parses the various fb_sig_ parameters and validates their signature
using md5 and the app's secret. It then saves the user_id and the
session_key in the server-side session. When using an iframe inside
facebook, this is typically the case for the first request.
2) If there are no such parameters, it checks the server-side session.
When using an iframe, this is typically the case for all the
subsequent ajax requests, or for subsequent requests that originate
from links inside the frame. This alleviates the need to pass all
those parameters with each request. (in the php code this is done with
cookies. I changed it so it is done with the server-side session)
3) If there is no such information in the session, then it looks for
the auth_token parameter, and uses it to create a user_id and
session_key. This is the case when the request is the result of a
facebook login page redirect.
4) When all else fails, do nothing. At this state, the object is not
associated with a user_id or a session_key at all. This is where
methods like requireLogin(), requireAdd(), isAdded(), etc. kick in.
> As you can see, the Facebook object is not designed to be kept in the
> server-side session. You need to create a new one and then discard it
> with every request that comes. It associates itself with a request-
> response pair so it can issue a redirect properly if necessary. This
> is not to my particular taste, and I know it can be done differently,
> but I copied the object from the php library almost line-by-line, and
> it was important for me to preserve the same semantics (albeit with
> some exception to adapt the code for Java specific features).
> I'm using an iframe for my application, not fbml, so I only had a
> chance to test this in a stand-alone webapp (accessing it locally athttp://localhost:8080/myapp/) and inside facebook via an iframe.
> In both cases the method requireLogin does what it is supposed to do.
> It returns a boolean flag indicating whether or not a redirect to
> Facebook's "login to this app" page was issued.
> My application happens to also have a servlet that is serving ajax
> requests. It requires access to FacebookRestClient, so I keep it in
> the session. As you can see, it happens to be that this object in the
> session gets overwritten with every request. I think this is not the
> ideal design, but I doubt if this is a big deal, unless you are facing
> serious performance issues.
> The magic is of course in the constructor. It does the following:
> 1) Parses the various fb_sig_ parameters and validates their signature
> using md5 and the app's secret. It then saves the user_id and the
> session_key in the server-side session. When using an iframe inside
> facebook, this is typically the case for the first request.
> 2) If there are no such parameters, it checks the server-side session.
> When using an iframe, this is typically the case for all the
> subsequent ajax requests, or for subsequent requests that originate
> from links inside the frame. This alleviates the need to pass all
> those parameters with each request. (in the php code this is done with
> cookies. I changed it so it is done with the server-side session)
> 3) If there is no such information in the session, then it looks for
> the auth_token parameter, and uses it to create a user_id and
> session_key. This is the case when the request is the result of a
> facebook login page redirect.
> 4) When all else fails, do nothing. At this state, the object is not
> associated with a user_id or a session_key at all. This is where
> methods like requireLogin(), requireAdd(), isAdded(), etc. kick in.
...it isn't bundled with the main project because it introduces a
dependency on servlet-api, which would be inconvenient/confusing for
anyone with a desktop app (since they're almost certainly not using
servlets).
On Jan 28, 4:50 pm, Travis Reeder <tree...@gmail.com> wrote:
> > As you can see, the Facebook object is not designed to be kept in the
> > server-side session. You need to create a new one and then discard it
> > with every request that comes. It associates itself with a request-
> > response pair so it can issue a redirect properly if necessary. This
> > is not to my particular taste, and I know it can be done differently,
> > but I copied the object from the php library almost line-by-line, and
> > it was important for me to preserve the same semantics (albeit with
> > some exception to adapt the code for Java specific features).
> > I'm using an iframe for my application, not fbml, so I only had a
> > chance to test this in a stand-alone webapp (accessing it locally athttp://localhost:8080/myapp/) and inside facebook via an iframe.
> > In both cases the method requireLogin does what it is supposed to do.
> > It returns a boolean flag indicating whether or not a redirect to
> > Facebook's "login to this app" page was issued.
> > My application happens to also have a servlet that is serving ajax
> > requests. It requires access to FacebookRestClient, so I keep it in
> > the session. As you can see, it happens to be that this object in the
> > session gets overwritten with every request. I think this is not the
> > ideal design, but I doubt if this is a big deal, unless you are facing
> > serious performance issues.
> > The magic is of course in the constructor. It does the following:
> > 1) Parses the various fb_sig_ parameters and validates their signature
> > using md5 and the app's secret. It then saves the user_id and the
> > session_key in the server-side session. When using an iframe inside
> > facebook, this is typically the case for the first request.
> > 2) If there are no such parameters, it checks the server-side session.
> > When using an iframe, this is typically the case for all the
> > subsequent ajax requests, or for subsequent requests that originate
> > from links inside the frame. This alleviates the need to pass all
> > those parameters with each request. (in the php code this is done with
> > cookies. I changed it so it is done with the server-side session)
> > 3) If there is no such information in the session, then it looks for
> > the auth_token parameter, and uses it to create a user_id and
> > session_key. This is the case when the request is the result of a
> > facebook login page redirect.
> > 4) When all else fails, do nothing. At this state, the object is not
> > associated with a user_id or a session_key at all. This is where
> > methods like requireLogin(), requireAdd(), isAdded(), etc. kick in.
|
