Facebook Authorization using LWUIT Browser - java-me

I am facing problem with LWUIT browser in conjunction with Facebook OAuth API.
I am trying to authorize our application to use Facebook services on a mobile client using LWUIT browser, which is available on SVN. I can go as far as the permissions page where you see a list of permissions followed by the "Allow" and "deny" buttons. The moment I click on the "Allow" button, I am again being redirected to Facebook login page (m.facebook.com) instead of forwarding to our application webpage. Has anyone encountered this problem and has managed to get around it?
From my understanding, I believe there is a problem in parsing the page and hence there is a failure in generating an access code which in turn is responsible for forwarding back to the application webpage.
I'd really appreciate if anyone could shed some light on the predicament.
Thanks

You need to have a simulator with the proper certificate chain from Facebook. Try Java SDK 3.0.5 or newer (the very latest ME SDK). This is an SSL problem in a few J2ME mobile stacks.

Related

When trying to login to Google's OAuth 2.0 in embedded webviews users get disallowed_useragent

We are advertising our product on Facebook and Linkedin. When users click on our ads, a webview opens with an opinion for Google SSO as a sign-up option. We support only webview at the moment.
The Google OAuth as a sign-up/login mechanism works on desktop and mobile, but when the site opens inside a mobile app such as Facebook, the user gets this error shown.
the error leads to: https://developers.google.com/identity/protocols/oauth2/web-server#authorization-errors-disallowed-useragent
As I understand Google wants us to set 2 configuration files in our site route directory, "apple-app-site-association.json" file for iPhone and "AndroidManifest.xml" for android.
I'm trying to configure them, but I don't understand how to without a mobile app.
This is expected due to security changes to Google's OAuth 2.0 authorization endpoint, you can find more details here

UWP side loaded app distribution from AAD-protected web site

I've got a LOB UWP application which I want to distribute via the web using the web-based sideloading experience. This is fairly simple using the VS deployment tools which output an HTML file and the required resources. My goal is to publish the assets to an Azure web app and turn on Easy Auth so that only people from my org can reach the installer landing page.
This works fine for restricting access to the html page, but the links which point to the actual installer file fail. I'm guessing it's a mime type issue where the auth middleware doesn't know how to handle an Http request with auth information for a non-standard file type:
I'd appreciate any guidance or suggestions
Microsoft confirmed over on techcommunity.microsoft.com that this is not possible as of yet, but that a solution to support this scenario is on their backlog:
You're correct - the problem is that App Installer is making its own
auth request without the inherited web auth tokens. Sending
authenticated requests is currently not supported today but this is an
item in our backlog and we're working to address this issue.

How to restrict website to get opened only from UWP, not from browser

I have a website hosted on azure. The website is expected to get opened only from the UWP application and should be prevented to get open from browser directly. I was checking deep linking Web-to-App approach. Are there any other options to do this?
The only way you could do this would be to setup some kind of client authorization mechanism in a way that the app would add some additional request headers to with authentication information that the server would check to verify that the client is indeed the app.
You should look into IdentityServer4 documentation, as they show how such functionality can be implemented. You could implement this yourself or use IdentityServer4 or some other tool in the respective language you use on your backend.

Facebook Login completely server side

The goal is to build a Facebook USSD platform. Completely server side. Allowing the user to log in and then create a facebook post, see their feed, etc.
I know there are companies in the world that is doing this and its working fine (u2opia mobile being one of them). However how on earth to log a user into Facebook and get an access token for them without OAuth? I cannot seem to find any help online to log a user in completely on server side with NodeJS. Do these companies have a special arrangement with Facebook in order to log in users without OAuth and Internet?
Is it at all possible in 2018 to log in a User into Facebook completely server side? I am just finding a lot of old posts from 2012 and 2014.
Yes, it is possible to log a user in completely server side. You can build an implementation manually with browser redirects. Facebook has a tutorial on this. Their page states:
if you need to implement browser-based login for an app without using our SDKs, such as in a webview for a native desktop app (for example Windows 8), or a login flow using entirely server-side code, you can build a Login flow for yourself by using browser redirects.
Here is the tutorial: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/

Using Google Authenticator with Chrome Plugins

I am developing a chrome plugin which allows the users to email any web content from a html page. For that, I need to use the google authenticator api to allow users to log into their google accounts for sending emails. The OAuth2.0 specs require the redirect_ui parameter which is the url to be called after google authenticates the user. My question is whether it is possible to skip this parameter. I don't want the plugin to be hosted anywhere. I am thinking that it would be hosted locally on the user's machine.
Thanks in Advance.
Google has made a library specifically for using OAuth in Chrome extensions. You can check out the tutorial here.
In case someone stumbles upon this answer in 2017+, extensions (in Chrome and FF) now have a chrome.identity API.
It takes care of the OAuth dance for you, and provides you with a virtual redirect address https://<your-extension-id>.chromiumapp.org/ that will be intercepted by the browser. That way, you can provide a redirect URL without hosting anything.

Resources