signed_request processing by RestFB
Gennady Shumakher
application should make sure that the data it's receiving is the
actual data sent by Facebook.
http://developers.facebook.com/docs/authentication/canvas
(signed_request) describes the details of new technique implemented
with PHP.
I wonder whether RestFB is planed to provide such functionality out of
the box?
Thanks,
Gennady
revetkn
Thanks for letting me know - I didn't realize Facebook added this
functionality (don't use Canvas apps myself). I don't think this will
get into 1.6 but should be in the next release after that. I've
opened issue 75 for this: http://code.google.com/p/restfb/issues/detail?id=75
Mark
Gennady Shumakher
developers.facebook.com/docs/reference/fbml/), so canvas applications
should become a mainstream for UI integration within Facebook. So
support for 'signed_request' may be a nice addition for your excellent
library.
Thank you!
Gennady
Gennady Shumakher
I and colleague of mine (skl...@gmail.com) would like to contribute
to the library the java implementation of the mention above iframe app
authentication technique (described in http://developers.facebook.com/docs/authentication/canvas
-> signed_request). I think you use different libraries for encoding
and JSON serialization, so the code should be adjusted, but I believe
you still can benefit from the most of it:
import org.apache.commons.codec.binary.Base64;
import org.codehaus.jackson.map.ObjectMapper;
.....
// http://developers.facebook.com/docs/authentication/canvas
Map<String, String> validateSignature(String signed_request, String
appSecret) throws Exception {
if (signed_request == null)
throw new Exception("Invalid signature.");
String[] parts = signed_request.split("\\.");
if (parts.length != 2)
throw new Exception("Invalid signature.");
String encSig = parts[0];
String encPayload = parts[1];
Base64 decoder = new Base64(true);
Map<String, String> data;
try {
data = new ObjectMapper().readValue(new
String(decoder.decode(encPayload)), HashMap.class);
} catch (IOException e) {
throw new Exception("Failed to parse JSON session.", e);
}
try {
Mac mac = Mac.getInstance("HMACSHA256");
mac.init(new SecretKeySpec(appSecret.getBytes(),
mac.getAlgorithm()));
byte[] calcSig = mac.doFinal(encPayload.getBytes());
if (Arrays.equals(decoder.decode(encSig), calcSig))
return data;
else
return null;
} catch (InvalidKeyException e) {
throw new Exception("Failed to perform crypt operation.", e);
}
}
Best Regards,
Gennady
revetkn
Nice, I'll try to fit this into 1.6 minus the Jackson and commons-
codec bits. Will post here if it makes the cut for that release.
Thanks
Mark
> I and colleague of mine (skla...@gmail.com) would like to contribute
> authentication technique (described in http://developers.facebook.com/docs/authentication/canvas
> -> signed_request). I think you use different libraries for encoding
> and JSON serialization, so the code should be adjusted, but I believe
> you still can benefit from the most of it:
>
> import org.apache.commons.codec.binary.Base64;
> import org.codehaus.jackson.map.ObjectMapper;
> .....
Fernando Padilla
revetkn
Thanks for the reminder. Right now this is targeted for 1.7 per the
enhancement request linked in my September 12th message above. Kind of
easy for this feature to fall through the cracks because I don't use
it myself ;) ...but I will look at getting this done soon because 5
people have starred the issue.
Thanks
Mark
Fernando Padilla
What's the likelihood of moving off of java.util.logging, and just using
Slf4j directly? Supposedly translating from JUL to SLF4J (so i can use
log4j) is very expensive.
Just asking. :) :)
Fernando Padilla
org.json jar file, instead of including a direct copy of the library?
I mention this, since I bet the main argument for both of these requests
are that you were trying to reduce the number of "dependencies". But, I
think you'll have to reconsider this at some point in the future. :)
revetkn
> What's the likelihood of moving off of java.util.logging, and just using
> Slf4j directly? Supposedly translating from JUL to SLF4J (so i can use
> log4j) is very expensive.
to RestFB. However, if you are running into performance issues with
logging, please post your benchmarks and we can decide how serious the
problem is and see if it makes sense to make a change. But my gut
says that these numbers would likely be trivial next to the time spent
on the network talking to Facebook (numbers out of my ass: 5ms vs.
500ms), and the overhead of JSON parsing using the org.json bits would
likely be much greater than logging overhead. If you do need the
highest performance possible, it might be best to look at batching up
your requests and then processing the responses using Jackson's
streaming JSON parser - the BatchFB project is optimized for this case
and may be a better fit. You can also use RestFB and tell it to map
its results to String and then use Jackson yourself, too. Or get
really crazy and feed the HTTP response InputStream to the parser
directly instead of reading it all into a String first and processing
after. The rabbit-hole goes deep!
> actually for that matter.. now that we're maven, can we depend on
> org.json jar file, instead of including a direct copy of the library?
>
> I mention this, since I bet the main argument for both of these requests
> are that you were trying to reduce the number of "dependencies". But, I
> think you'll have to reconsider this at some point in the future. :)
like. I think the best single-purpose Java libraries out there like
Guide, Joda-Time, and Ehcache are great examples of this self-
contained, small-footprint concept: they do their one thing and do it
well and don't introduce a bunch of other stuff into your project that
you might not want or need. I try to follow in those footsteps
because that's what I like to see in an open-source project.
Yes, if your project is a Maven project, Maven will take care of the
dependencies for you. And for us non-Maven users, it's a simple
matter to copy dependency JARs to your classpath. But just because
it's easy to add dependencies to a project doesn't mean I have to like
it :)
Thanks
Mark
Chris Pruett
I had the same concern, but discovered that if you're using logback
+slf4j, you can eliminate the overhead with the LevelChangePropagator
http://logback.qos.ch/manual/configuration.html#LevelChangePropagator
Chris.
revetkn
I'll add a link to this on http://restfb.com since it might be useful
for others too.
Mark
On Feb 2, 1:55 pm, Chris Pruett <chris.pru...@gmail.com> wrote:
> Fernando,
>
> I had the same concern, but discovered that if you're using logback
fernando padilla
Right. But if most people use log4j or slf4j. Then why are we forcing them to use jul?
revetkn
This is my reasoning.
If I were to choose slf4j, then everyone using log4j must add slf4j to
their projects.
If I were to choose log4j, then everyone using slf4j must add the
log4j adapter (or whatever it's called) to their projects.
If I were to choose commons-logging, then everyone not using that must
add it to their projects. Plus I don't like commons-logging, although
from what I hear the classloader problems etc. have been fixed since I
last used it.
By using j.u.l I avoid this. I originally started on 1.6 by having 3
different distros, one that supported log4j, one that was j.u.l, and
one that was commons-logging. I (rightfully IMO) got negative
feedback and I decided to go with j.u.l, and if anyone wants to tie
into their own logging framework, it's simple enough to do with the
slf4j bridge.
If there were a clear cut "98% of apps use logging framework X"
metric, I would write RestFB to target logging framework X. But it's
not that simple, at least not so far as I know. The state of logging
in Java is a bit ridiculous, unfortunately, and it's not going to
change anytime soon, if ever.
Thanks
Mark
On Feb 2, 2:37 pm, fernando padilla <fern...@gmail.com> wrote:
> Right. But if most people use log4j or slf4j. Then why are we forcing them
> to use jul?
>
Marcel Stör
On 02.02.11 20:55, revetkn wrote:
> Hi Fernando -
>
> This is my reasoning.
>
> If I were to choose slf4j, then everyone using log4j must add slf4j to
> their projects.
> If I were to choose log4j, then everyone using slf4j must add the
> log4j adapter (or whatever it's called) to their projects.
> If I were to choose commons-logging, then everyone not using that must
> add it to their projects. Plus I don't like commons-logging, although
> from what I hear the classloader problems etc. have been fixed since I
> last used it.
>
> By using j.u.l I avoid this. I originally started on 1.6 by having 3
> different distros, one that supported log4j, one that was j.u.l, and
> one that was commons-logging. I (rightfully IMO) got negative
> feedback and I decided to go with j.u.l, and if anyone wants to tie
> into their own logging framework, it's simple enough to do with the
> slf4j bridge.
>
> If there were a clear cut "98% of apps use logging framework X"
> metric, I would write RestFB to target logging framework X. But it's
> not that simple, at least not so far as I know. The state of logging
> in Java is a bit ridiculous, unfortunately, and it's not going to
> change anytime soon, if ever.
I don't agree with you but I respect your stance.
Since this subject comes up so often I think it deserves its own chapter
on http://restfb.com/. For all future requests to support logging
framework X you could simply post a link...
Should you ever change your mind I'd use slf4j - unless something better
is developed in the meantime ;-)
Cheers,
Marcel
--
Marcel St�r, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
revetkn
If it's any consolation, if I do reintroduce a logging framework, I
will likely go with slf4j. From a technical perspective, it's the
best Java logger available, I just wish it were more popular!
Thanks
Mark
>
> Should you ever change your mind I'd use slf4j - unless something better
> is developed in the meantime ;-)
>
> Cheers,
> Marcel
>
> --
Marcel Stör
> Hi Marcel -
>
> If it's any consolation, if I do reintroduce a logging framework, I
> will likely go with slf4j. From a technical perspective, it's the
> best Java logger available, I just wish it were more popular!
Umh, what tells you slf4j is not popular? Do you have "facts & figures"
that support your statement? I'd be interested in that because I'm never
quite certain about the user base of the various logging frameworks
myself...
As I said before, I don't agree with not introducing dependencies but I
totally understand your reasons. Earlier in my career I supported the
same ideas you brought forth wholeheartedly.
I hope for one thing though. If you ever change your mind then don't
just add a logging framework X dependency. Either introduce dependencies
and replace all the duplicated hand-woven code (logging X, Apache
commons lang, etc) or stick with your ideals.
Cheers,
Marcel
>> Marcel St�r,http://www.frightanic.com
>> Couchsurfing:http://www.couchsurfing.com/people/marcelstoer
>> O< ascii ribbon campaign - stop html mail -www.asciiribbon.org
--
Marcel St�r, http://www.frightanic.com
Fernando Padilla
though, it sorta sounds cyclical. I don't want to add dependencies, yet
you want slf4j to be more popular. You want people to step beyond their
fear of a new logging framework, yet you won't push them out of the nest
our of fear of a few new dependencies.
anyhow.. it's not a blocker right now. :) I mean you just moved into
the maven central a few weeks ago.. we can wait a bit longer for a good
logging framework. :) :)
thank you for everything though! :)
free beers available when in SF :)
On 2/6/11 6:33 AM, revetkn wrote:
> Hi Marcel -
>
> If it's any consolation, if I do reintroduce a logging framework, I
> will likely go with slf4j. From a technical perspective, it's the
> best Java logger available, I just wish it were more popular!
>
> Thanks
> Mark
>
>> Marcel St�r,http://www.frightanic.com
revetkn
revetkn
> Umh, what tells you slf4j is not popular? Do you have "facts & figures"
> that support your statement? I'd be interested in that because I'm never
> quite certain about the user base of the various logging frameworks
> myself...
informed decision. For apps that I've seen/had involvement with,
commons-logging backed by log4j has been the most popular choice, then
just about a tie between slf4j and jul (probably an insignificant
sample size since I'm one person, but hey...)
It's kind of like the old argument, where I say "I haven't seen any
pink elephants" and you say "you can't prove they don't exist!" But
practically speaking I don't know how to get good logging usage
numbers, so my point is a little less valid :) Maybe Maven Central
(or whatever) keeps track of dependencies for all Maven projects has
some stats on this?
> As I said before, I don't agree with not introducing dependencies but I
> totally understand your reasons. Earlier in my career I supported the
> same ideas you brought forth wholeheartedly.
and I still do for non-library projects. Now that I'm an old man, I
don't like dependencies in my libraries unless they're totally
necessary.
Mark
