I'm building a native application. The app has an embedded webview (UIWebView) pointing to a social website. To be able to use the website inside the app, user has to log in by the webview (username/password) and then he can continue use the site with saved cookies. Normally, the cookies expire after two days. After that, the user has to re-login by the webview.
Now suppose I know username and password of the user and I would like to make the user login automatically with this account when the cookie expires. How can I do that?
I tried to simulate the Login action when I click on Login button on web page, but not successful.By using "Inspect Element" of Chrome, I can see Chrome makes a "Post" request to an URL with some parameters. However, the request doesn't get successful (I use REST client for testing).
Finally I found out the solution. I didn't build requests anymore. I used javascript to set text fields and make "click" action on the webview. Done.
Related
I have an iOS app, using a native login, based on the custom example.
This works perfect and I am happy with it.
I have a requirement to open an embedded WKWebView within my app, that SSO’s a user in.
The url looks something like this:
https://{my-okta-org}.com/app/{some-okta-app-id}/exkms5nzsh0tD0kO10h7/sso/saml?RelayState={some-relay-state}
When I launch this however within my web view, I am redirected to an Okta login page. I would expect this really as the embedded view has no context of the authenticated session.
How can I set my session against this webview without asking the user to sign in again? As I have used the native login, I do not have a cookie set, so I suspect I will need to request one but am unsure of the flow required in this case.
I would recommend to not use WKWebView for SSO 1.Not secure, using javascript you can get user login and password 2.Cookies not share between your session and Safari(you are loosing all SSO magic) 3.WKWebView has problems with cookie synchronizing Apple thread and you need manually manage your cookies
The flow of application requires user to go to a webpage and update few details after which the user need to come back with id that website has provided.
Working senario:
User logs in application
clicks button goes to the website update few details
stays in the Webview for the website
Required Senario:
Should come back to the app with the id that website provided
The flow of the app is something similar to google Oauth where the user clicks the google button to authenticate google to use the google account.
You can show the web page in a WKWebView. Assuming you also are coding the web page you can also use evaluateJavaScript(:completionHandler:) to figure out when the website is done, grab the result, and dimiss the WKWebView. Alternatively you can intercept the success navigation with the WKNAvigationDelegate method webView(:didStartProvisionalNavigation:) and then grab whatever info you need from the server.
I am embedding a Facebook app https://example.com into the Facebook app canvas so that it is available at https://apps.facebook.com/EXAMPLE . My application sends notification emails that contain links like https://example.com/messages/123 and that should open the page embedded into the Facebook canvas. How do I achieve this? My current thoughts:
User opens https://example.com/messages/123
Application checks for signed_request parameter
Application redirects user to https://apps.facebook.com/EXAMPLE/?requested_page=/messages/123
Application checks for requested_page parameter and redirects to this page
User sees https://example.com/messages/123 URL and is embedded into canvas
Is there a better pattern out there to get this working?
My final working solution (with Ruby on Rails)
User opens https://example.com/messages/123
Application checks on client-side if app is embedded in canvas:
if(window == top){
top.location = "https://apps.facebook.com/#{Settings.facebook.app_id}#{request.fullpath}";
}
User is redirected to https://apps.facebook.com/EXAMPLE/messages/123
Application middleware converts POST into GET if signed_request is present (code and idea borrowed from https://github.com/dekart/facebooker2/blob/master/lib/facebooker2/rack/post_canvas.rb)
Application parses signed_request with fb_graph gem
FbGraph::Auth.new(app_id, app_secret, :signed_request => params[:signed_request])
I'd just update the link to point to http://apps.facebook/example/messages/123 off the start.
When you check for authentication just set the redirect after authorization/login to the same page.
Redirecting a user around multiple pages for no reason is just not a good practice.
All,
Here is the scenario;
Our website uses APPID-1 for auth and extended permissions (MainSite)
Our Page Tab App uses APPID-1 for auth & extended permission
(TabApp-1), and this adds the auth_token to our DB on MainSite
However we want to add another tab that uses APPID-1 for auth_token acquisition, is this possible?
Proposed scenario;
MainSite - APPID-1 acquire auth_token
TabApp-1 - APPID-1 acquire auth_token
TabApp-2 - APPID-1 acquire auth_token
I should note that non of our TabApps actually need the auth_token, its our MainSite backend app that uses the auth_token to perform actions for the user. However we want to make it easier for our users to use the site, and many come via our Fan Page.
So can we have TabApp-2 pop the Auth Dialog for APPID-1 with is not TabApp-2's APPID?
Specs:
Ruby on Rails 3.1 and using Graph API & Javascript Fb API
I guess you would have to initiate the JS SDK in TabApp-2 with APPID-1. Server-side you would receive a signed_request with TabApp-2 credentials but you can just it that if you work only with the JS API.
I guess you could validate the assumption with a prototype in less than 30 minutes. Have you done that yet? If so, what were the results?
You don't need different apps for this (but i think you're aware of that) the same app can be installed onto multiple pages, and you can show different content on each page by checking the page parameter in the signed_request which is POSTed to your server when the page tab is loaded by a user.
As far as authorisation goes, you may have issues when getting the user to log in directly from a page tab (issues = it may not be allowed to redirect the user back to the tab after login because the full URL to the tab (http://www.facebook.com/pages/somepage/12345?sk=app_{app id here}) isn't 'owned' by your app)
If that happens you can send them to your main site after login with an additional parameter that you use to detect that the user started login on a page tab, and redirect them back to it
Seems you will have to make a few apps, then just use php-sdk to authenticate, since the auth will be server side it will not matter what iframe or page tab it appears in, it will be able to auth to a single app.
I feel incredibly stupid for even asking this since the answer might already be under my nose but here it goes:
TweetMeme has a Re-tweet twitter widget that publishers can place on their blogs. When a user clicks on the widget, it pops open a window which allows the user to authenticate themselves with twitter and then re-tweet.
This seems to use some special Twitter oauth popup form factor - unless there is something fancier happening under the surface to authenticate the user.
The pop-up window looks like this:
http://twitpic.com/1kepcr
I'd rather handle an authentication via a pop-up rather than send the user to a brand new page (for the app I'm working on) and they seem to have the most graceful solution. Thoughts on how they did this?
I think that the process is something like this (I assume that they have used php on server-side):
First it opens a jQuery-like popup, but it's not strictly related to twitter sign in functions.
The real sign-in process begin when you confirm that popup, so it open new popup, with some php inside, that # hold a session.
Those scripts ask to twitter the request tokens, using site's application params, and save them into $_SESSION array.
If it's all-right, twitter send you to twitter authenticate page (https://twitter.com/oauth/authenticate), and after you have inserted your login params, twitter send you to the callback page defiend by that site. Here there is another php page that request access tokens, and save them into $_SESSION array. If it's all-right now the site has params that he needs for querying your profile, so last scripts inside popup refresh opener window (main site) and close himself.
Now main window has all the interesting params inside $_SESSION array.
Check this useful library for all the server-side work.
All they're doing is opening a page http://api.tweetmeme.com/share?url=someURL&source=tweetmeme in a new window (using target _blank), then starting the process from there.
EDIT: I was looking at the wrong retweet button. For your specific example, clicking the retweet button first opens Tweetmeme page http://tweetmeme.com/ajax/partial?... in a new window. Clicking yes then initiates the OAuth process by sending you (still in that window) to https://twitter.com/oauth/authenticate (with appropriate parameters).