For an app I'm, building I need to be able to determine a Facebook user's relation to the page of which the app is being shown within. I hope to provide the following functionality:
1) If the user likes the page, direct them to another page
2) If the user doesn't like a page, direct them to another page
3) If the user is an admin of the current page, direct them to another page
The Auth Hash schema (https://github.com/intridea/omniauth/wiki/Auth-Hash-Schema) doesn't provide info of how to access user likes, or indicate a way whether they: a) Like or don't like the current page, or B) are an admin of the current page.
Furthermore I've researched around the internet but cannot find any specific Ruby or Sinatra example of how to do this. The closest that I've come to is (https://github.com/chrissloan/sinatra-book/blob/master/app.rb), however this users FBGraph (I'm using Omniauth-Facebook) and this script doesn't make any distinction between admin users of the page.
Therefore I'm wondering if my method of distinguishing between users on the page tab is inherently wrong and am wondering if there is another process of achieving the desired goals.
So in summary, I'm attempting to create:
A backend that is accessible by the app admin. When an app admin goes on the page, the admin panel is displayed.
A front end that displays whether the user has liked the page or not, and shows them specific content based upon this state - a 'like-gate'.
Thanks for reading and if you could help it would be very much appreciated.
Some code I've thought up, but from the docs I'm unsure of whether it is valid syntax or not. From begin is the experimental piece, the code above works and is currently being used.
get '/auth/:provider/callback' do
content_type 'application/json'
JSON.generate(request.env)
auth = request.env["omniauth.auth"]
puts auth
=begin
if auth['page']['admin'] == true ***not sure if admin is valid syntax***
#check user database and move to admin side
else if auth['page']['liked'] == true
#allow to download endpoint
else
auth['page']['liked'] = false
#direct to wall to like
end
I solved this by authorising with OmniAuth and then getting the signed_request generate from Facebook when the user opens the app on a Facebook page.
Related
I have a public page with a data-request = onClaim button.
A user can use this button whether he is logged or not
When the user "claims" this page, if certain conditions are fulfilled, the database must be updated and then a specific restricted access page have to be displayed with the new updated datas.
If conditions are not met, user stay on the public page with warning message.
To know if these conditions are met, the user must be logged in (using his account or creating new one)
note:
When the restricted page is displayed by any other way than this button. No specific data is updated
hard to explain, do my best !
Please, How to implement this workflow elegantly (or not)?
development environment:
october 419
rainlab User plugin
debugbar 1.0.8 plugin
sweet alert 1.1.0 plugin
i tried some tricks but according to the xy problem, i prefer don't talk about
I have a Mechanize script that currently goes to a login form and properly logs a user in. I'm seeing plenty of documentation to follow links, but I'd like to go to an ad-hoc page that isn't linked on the main page after I login. The page requires authentication and that's why I force the login first. Is there a way to change to another URL (that's still part of the same site) with Ruby's Mechanize gem and have it retain all of the cookies from the login? I looked up methods such as link_with but that's to follow a link on the current page. I'd like to go to a different url within the same website.
I believe you just need to make a subsequent get call after your initial transaction is complete.
client = Mechanize.new
client.get('http://example.com/login') do
# handle login
end
client.get('http://example.com/something-else') do
# another action
end
Here is my Gwt App, I have many pages: CustomerPage, OrderPage,... Each of these pages will have a header that have a Login Panel on top & its own content in the middle like this:
1- Customer Page
____________UserName...... Password....... Login
Customer Content here.....
2- Order Page
____________UserName...... Password....... Login
Order Content here.....
This means user can sign in in any page, they don't need to go to homepage to sign in.
Then here is my question, When user is in a certain page (ex: CustomerPage) & if they Log out then:
1- Should I refresh the whole page or redirect users to a Logout Page, so if they want to reopen the CustomerPage, then the page will have to go through all the Initializing processes (onBind-onReveal-onReset...)
2- Should I just let user stay where they are, and when user clicks logout button then system will reset variables. By doing that, then if user logs back in, the page will run faster cos it doesn't have to go through all the (onBind-onReveal-onReset...). However, if i do that then it quite difficult for me to reset all the variables. I have to remember which variables already initialed at the time the page got loggined & try to reset it to null or empty string. If i miss resetting just 1 variable then i will have trouble.
Some big site like Google or Facebook are using the solution 1, ie when user signs out it will redirect to new page or go back to homepage.
Also If adopting the solution 1, then i just need to call Window.Location.reload(); & it will reset everything. Even user clicks Back Arrow, they won't be able to see the old data since everything was reset.
So:
Is it Good Practice to redirect to a new Page or staying at the same page When user logged out (GWT)?
When users click on a Logout button, they expect that they can walk away from a computer. If you continue to show the same page, someone else might gain access to the data.
The universally accepted approach is to hide all data (i.e. redirect to the login/home page or close the app completely) when a user logs out. That's what users expect, and this is what you must do.
It depends what you've got loaded into the browser. Log in/out via a page refresh will be slower and present lag to your user. If you properly cleanup after yourself on logout (delete server side session, unbind presenters, clear caches) then it is really optional to refresh the page.
The universally accepted approach is to hide all data (i.e. redirect
to the login/home page or close the app completely) when a user logs
out. That's what users expect, and this is what you must do.
If your session management server side prevents any RPC's once you've logged out, and you no longer present/cache data, this is not an absolute necessity. Use digression based on your app needs, size, load time, and the sensitivity of the data it conveys.
I see where this method is being used, but I'm wondering who has an authoritative answer on the matter?
I know you said you know where, but I'm going to mention it here for completeness since you didn't... hope you don't mind! :)
The flag that isFirstPageAfterLogin() checks is set in the login() method that's called during the admin login process.
It is used in the following places:
Mage_Adminhtml_IndexController to store the value in the admin session so that it's still available on the first page load after the login form is submitted.
Mage_Adminhtml_Block_Notification_Window to determine whether or not to show the notices "window" that often shows after login.
A few actions on Mage_Adminhtml_Report_StatisticsController in order to redirect the user to the page they should be if their login routes them to one of the report refresh actions.
Mage_Core_Controller_Front_Action uses it to redirect a user back to the dashboard if their login routes them to an action that would send a download response, which frequently can rely on filter data that may or may not be available to the controller if it come from the login.
So to recap, it's a very important flag that is used to control some behind the scenes behavior. The most important being redirecting to the correct login page and allowing for one-time notices to show upon login.
This value is used in Mage_Adminhtml_IndexController, specifically the indexAction(), and redirects the admin user to the start up page defined in System > Configuration > Advanced > Admin > Startup Page.
I'm trying to dig around into an idea where we want to close a webiste for upgrades. So when a user hits our site, they are promptly re-directed to a page that tells them that the site is down for maintenance.
Theoretically, the entire process starts in the global.asax under the event session_start. We fire a command to the webservice to see if the service is down - if it is down, a false value is returned and the user is rerouted to a page that says the site is down otherwise normal operations continue. This is a non-password site.
Here's the idea with pages:
welcome.aspx
siteisdown.aspx
page1.aspx
page2.aspx
When the user visits the site, the code checks to see if the rest of the site is down for maintenance and if so, then the user is re-routed to siteisdown.aspx
We have that basic part down - but the real understanding is, the user - while still in the siteisdown.aspx page, could enter page1.aspx and continue on their merry way.
What we want to is is if the user enters page1.aspx they should be kicked back to siteisdown.aspx
What articles should I be looking at for this type of method? Forms Authentication?
There is already a feature for this built in. Deploy a static HTML file called "App_Offline.htm" to the root of your application and all requests will be routed there.
http://weblogs.asp.net/scottgu/archive/2005/10/06/426755.aspx