As a relative newbie to Rails, I'm not sure how to approach this. I am looking to add a basic "Login with Facebook" feature to a practice site I am developing. I am stuck on two fronts:
Most Rails plugins dealing with Facebook seem out of date or poorly documented. I've encountered Facebooker (seems to have died off from what I see) and Mini_FB (more recent, but very little documentation). I tried to install Mini_FB, but I am still very unfamiliar about working with Gems. I ran gem install mini_fb, then bundle install, and finally added gem 'mini_fb' to my Gemfile, but my server complains of a no such file to load error. Are there any other steps necessary to allow your app to use a gem?
I am confused by how the "Login with Facebook" feature works from an overall birds-eye view. I understand that my App ID is passed into the login feature, and I ultimately get an access token (after resubmitting with my App Secret Key and an authorization code). But how does this integrate with some kind of user system on a Rails site? Since this access code doesn't last forever, do I need to renew it periodically? Is that done by simply waiting to catch an access token error from a Graph request and redoing the entire authorization procedure?
Have you tried OmniAuth?
It supports a whole host of external providers, including facebook.
There are also a number of railscasts on it's use.
The correct order of installing a gem on your application would be first adding it to your Gemfile.rb, then running bundle install on your console. That being said, OmniAuth is probably the best path for you
Related
I am developing a web app with Facebook integration and I can't figure out why I can't test the login function locally. I have looked through the answers here (How to Test Facebook Connect Locally) and have tried to follow the steps of having the app in test mode, setting the site URL and the domain.
Based on FBs documentation here: https://developers.facebook.com/blog/post/2018/06/08/enforce-https-facebook-login/
I should be able to use http for localhost development, but I get the error
The method FB.api can no longer be called from http pages. https://developers.facebook.com/blog/post/2018/06/08/enforce-https-facebook-login/
and can't log in. Below are pictures of my app settings (including an indication it is an app in 'test mode').
So this is really only a half answer, but it seemed easier for me to just force https for my local development using mkcert (https://github.com/FiloSottile/mkcert). After creating local certs I updated my site URL to say https://localhost:8080 and I am able to log in without issue.
I'm having difficulty in integrating AEM 5.6.1 with Site Catalyst. It allows me to connect in the configuration successfully, but does not work on the framework setup.
I've followed the standard procedure to connect AEM to SC and it accepts my login in the configuration, but fails on the framework set up with the browser message 'We were not able to login to SiteCatalyst. Please check your credentials and try again.'. Behind the scenes in the server log;
12.12.2014 14:10:06.967 *WARN* [0:0:0:0:0:0:0:1 [1418393406764] POST /libs/cq/analytics/sitecatalyst/service.json HTTP/1.1] com.day.cq.analytics.sitecatalyst.impl.SitecatalystHttpClientImpl Data center 'https://api3.omniture.com/admin/1.3/rest/' responded with errors {"error":{"code":500,"message":"Internal Server Error"}}
12.12.2014 14:10:06.967 *ERROR* [0:0:0:0:0:0:0:1 [1418393406764] POST /libs/cq/analytics/sitecatalyst/service.json HTTP/1.1] com.day.cq.analytics.sitecatalyst.impl.servlets.SitecatalystServlet Call to SiteCatalyst method 'Company.GetReportSuites' failed com.day.cq.analytics.sitecatalyst.SitecatalystException: not authenticated
I've tried accessing via the API Explorer and it works.
I've tried the troubleshooting guide without success.
I can log in to Site Catalyst, I'm an admin, I am in the web services access group.
I've tried using a clean install of CQ5.6.1 with geometrixx - it doesn't work either.
I've tried this from a server and from a localhost/dev machine with the same results. No proxy. I've even tried using the shared secret as the password but then it doesn't connect at all, and fails on the configuration screen.
What might cause this to fail?
If it doesn't work with a fresh install and Geometrixx, then it's probably an Adobe bug. That's typically the first thing support will ask you about.
I would also verify using Geometrixx Outdoors, or a more recent demo site, on your fresh install, just to ensure it's not an outdated ClientLib issue.
I know this isn't a direct answer to your question, but honestly, I would approach the integration differently. I've worked with the AEM-SC framework and it's buggy at best. It's very finicky, it doesn't REALLY work the way the documentation claims, and it requires that you're very specific about what Clientlibs are on the page.
Moving forward, I think using Adobe Dynamic Tag Manager is the better approach, for many reasons. My understanding is that it's Adobe's recommendation as well. I'd consider moving to that. In AEM 5.6.1, you'll have to customize your integration with DTM, but it's not very hard.
Solution: Add a property on the configuration node for sitecatalyst: (eg. /etc/cloudservices/sitecatalyst/my-sc-configuration)
server=https://api.omniture.com/admin/1.2/rest/
it also seems to work with newer API versions such as https://api3.omniture.com/admin/1.3/rest/
It would appear that for 5.6.1 it ignores the OSGi configuration, at least for the configuration screens. With this extra property, the framework page loads without error and allows selection of the RSID.
I used to be able see http requests made for sinatra in the window I started my sinantra application from.
I think that after sinatra upgrade I cannot see them any more and I don't know how to make it so. I don't need to log them into a file.
set :logging, true didn't help
ruby 1.8.7 (2010-08-16 patchlevel 302) [i386-mingw32]
rack (1.4.0)
rack-protection (1.2.0)
sinatra (1.3.2)
sinatra-advanced-routes (0.5.1)
sinatra-reloader (0.5.0)
sinatra-sugar (0.5.1)
This is a bug introduced in Sinatra 1.3.2. The commit that introduced it was intented to fix another bug where the logging was being done twice in certain circumstances, but obviously isn't quite right.
This request logging is done by using the Rack::CommonLogger middleware component, which is now only added in certain cases. The fix/workaround is to simply add it yourself. Add
use Rack::CommonLogger
to the top of your application file (after requiring Sinatra). Note that you might end up with the original problem of seeing requests logged twice in some situations (e.g. if your deployment setup is different from your development setup).
I'm using facebook connect on a website, it worked well with PHP SDK 3.0.1.
Now I've downloaded and started using PHP SDK v.3.1.1 and set Encrypted Access Token to enabled. It still works without problems. Is this enough for the migration? How can I check it? I don't use the js sdk.
According to the migration guide, it looks like you have done all the steps you need for Facebook on an external website by upgrading to 3.1.1 PHP SDK and set encrypted access token.
If you were hosting a fan page or app inside Facebook you would also need an SSL certificate. And there are several code changes required if you are using the javascript SDK which you say you aren't.
Is it possible to develop facebook using google app engine locally, without having to upload application every time I change it?
I assume you are getting API error 191 when you try to access the Facebook API from the dev appserver?
API Error Code: 191
API Error Description: The specified URL is not owned by the application
Error Message: redirect_uri is not owned by the application.
If you are developing on your localhost, you can set the 'Site Domain' field in your facebook app settings to (appname).appspot.com and then edit the HOSTS file on your system.
In my environment I just entered:
127.0.0.1 devlocal.(appname).appspot.com
As long as the browser's URL matches *.(appname).appspot.com, it will work.
You could set the Website field in your Facebook app settings to http://localhost:XXXX or http://127.0.0.1:XXXX for development and then change it over to the actual once ready for deployment. This worked well for me.
I ran into this issue a couple years ago and wrote a long article about how I solved it for my needs.
http://www.upwithabang.com/articles/GAE-facebook-win7.html
It covers the setting up of an Apache server on your laptop then telling Facebook and the GAE to behave as if it hosted on a production server. This solves the pain of constant uploads for testing every little change.
Hopefully this is helpful to someone, if not a little late.