In the event 'request_created' I check authorization. If the user is not logged in, then I want to cancel the current Request and assign a new Request for a page Login. How to do it?
In 1.x the framework doesn't allow for request "hijacking". So your best options would be to use Response::redirect in the event listener. Optionally you could store the current URL (Uri::current()) in the session for a post login-redirect. Version 2.0 will have multiple ways to take over the request by returning a response in various places during the request cycle.
Related
I am using webhook to create bot for page. I got everything but not getting where to get Callback URL
I think you're misunderstanding the concept of webhooks. The Callback URL is simply the location that you want Facebook to deliver messages to.
For example: if you are running a server at https://my_awesome_service.com and you want it to receive facebook updates, you would first create a route (let's say /v1/facebook_subscriptions) in your service. Once that's ready, you would insert https://my_awesome_service.com/v1/facebook_subscriptions into that Callback URL field. Facebook will then do a GET on that URL, which your server must reply to correctly. After that's done, Facebook will start sending you POST's, based on the subscription fields you set up.
There's a lot more information about this in the Facebook API Docs.
Callback URL(s)
A callback URL indicates where the user is to be redirected after a successful sign-in. Choose at least one callback URL, and it should:
Be an absolute URI.
Be pre-registered with a client.
Not include a fragment component.
See OAuth 2.0 - Redirection Endpoint.
Amazon Cognito requires HTTPS over HTTP except for http://localhost for testing purposes only.
App callback URLs such as myapp://example are also supported.
I am not sure if I am using the right terminology, but I was looking at the documentation and trying to work out if I could achieve the following with Shiro:-
Allow the user to login via a post of JSON
Check credentials and send a session ID to the user (probably on the header)
For every subsequent request, send the session ID transmitted on the login response on the request header
Use a SessionDAO which stores the session data in the DB (thereby creating a "sessionless" application).
I know how to create the session DAO, but I wasn't sure how to set the current subject on a web application. Is this possible? Is there any reason not to do this?
If you need to manage a session then the application is not sessionless. That said, take a look at the [DefaultWebSessionManager].(https://github.com/apache/shiro/blob/master/web/src/main/java/org/apache/shiro/web/session/mgt/DefaultWebSessionManager.java). Though, if you are going through the hassle of setting a header anyway, you could just set the cookie header, and use this implementation as is.
Im writing a user registration mechanism by hand so I dont want to use existing plugins or something.
Im wondering what the best way would be. I planning to do the following abstract steps:
Writing an component which is in charge to output a button which calls the facebook-api --> login in via facebook (Im getting token and user name/id)
In my route im using that Data to call the REST-Server-Backend of my app. I will pass the token as well as the username/id to the Server. (POST api.myapp.com/users)
The Server recieves the request and will validate via Facebook-API
the user data and token on its own --> if valid: Add new user to
database.
If the user wants to login now (after registration) he will do again
step no.1 and than will ask the server if the user is existing. But
how: Since ember suggest that the REST-Server is somekind of a
CRUD-Server and using the store is for working for model data only, there
is no possiblity to do a "logic"-call to the server like "ask
him if user with id is existing". Should I call "GET ../users/" and than check in my route if the sum of the returned records are smaller than 1?
So is that a common pattern?
Sounds like a fairly simple OAuth workflow but obviously refer to the facebook docs. As far as point 4 is concerned, I would suggest that yes, on login you make a request for the login route on your server (which should abstract the facebook OAuth call), and if the user is authenticated, then send down the user resource, otherwise redirect them to the login and send down some sort of 401 HTTP error.
As all your API calls should be authenticated too your user won't be able to access any protected API resources.
I would also suggest you look into an ember plugin like ember-simple-auth which also supports OAuth.
You can find more information about OAuth2 workflows here.
The documentation says that the app is responsible for deleting it's own requests. From a application design perspective, when is the best time to delete a request? Are there cases where the request should never be deleted?
btw, this is what I mean by deleting requests...
$facebook->api("/$full_request_id",'DELETE');
According to the documentation the most appropriate time to delete a request is immediately after the user is taken to your canvas application from clicking on a request. This removes the request from the various notification channels and updates the request counter. I would recommend a global hook that is configured to monitor the inbound Facebook request_ids GET parameter, look up the appropriate Facebook requests, optionally update your internal request/invite tracking, and delete the request once processed.
I don't believe there are any official policies regarding deleting your own application requests, and it would make sense to delete pending requests early, e.g. if the request is for a time-sensitive action that has past.
I need to send a request to a user using my custom dialog (which user has other options). After this, I have 'users_ids' to send requests.
Is it possible do this using Graph API?
(I did not find any way to do this at Requests Dialog.)
There are two types of requests as mentioned in the Social Channels documentation (section Requests): User-generated and App-generated.
You can send App-generated requests to the user both from the server and client side with out the need of using a dialog.
How ever you can send these requests only for a user who authorized your app, as it described in the connection in the user object.
The User-generated requests can only be sent using the dialogs, as the name implies.
The best source for this issue is the Requests documentation.