The simplest way to launch a web browser from within a blackberry app is:
Browser.getDefaultSession().displayPage(URL);
Is there any reason I would need to use Browser.getSession(UID) instead of Browser.getDefaultSession()? What does that provide for the average use of opening a web browser that the default session does not, if all I'm worried about is showing the URL provided?
getDefaultSession() returns the session for the default browser, getSession(UID) gets the session for the connection specified by the UID which might be: BES, BIS_B, WAP, etc.
The following links provide a great deal of information on network trasports and browser sessions:
http://supportforums.blackberry.com/t5/Java-Development/Network-Transports/ta-p/446834
http://supportforums.blackberry.com/t5/Java-Development/Networking-Transports-II/ta-p/446742
http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/800440/How_To_-_Invoke_the_browser.html?nodeid=1487366&vernum=0
Related
tl;dr; see the question below
In my app, I have a login that uses SFSafariViewController and ASWebAuthenticationSession that follows the OAuth 2.0 flow (Using the AppAuth library).
The login works and the cookies are shared with Safari as expected. Thanks to the cookie sharing, users are automatically logged-in if they use the Safari app.
However, back in the app, if I launch a SFSafariViewController again, the cookies are missing. This surprises me, because I thought the cookie Store is the same for SFSafariViewController and Safari, and it clearly worked in the direction from SFSafariVC to the Safari app during login.
Is it intended not to work the other way round - from Safari to SFSafariViewController, or is it a bug?
I have not found clear statements in the documentation.
Of course I have not set ephemeral session to true, but according to the documentation it would do the opposite of what I want to achieve:
When not using an ephemeral session, all cookies except session cookies are available to the browser.
I've also found somehow related radars like http://www.openradar.me/33323462 and http://www.openradar.me/radar?id=5036182937272320 or this stackoverflow post: Why is SFSafariWebViewController not sharing cookies with Safari properly? but they do not answer my question.
According to this comment it could work if the cookies have an expiry date (set to a future date). I verified the cookies - they all have a future expiry date.
My question: Am I doing something wrong, or is this expected behaviour, that SFSafariViewController does not get cookies from an earlier SFSafariViewController instance in the same app or from Safari?
REQUIREMENTS
So it seems you want a solution to invoke secured web content from a mobile app, and to avoid an extra login. It is a common requirement and I will be adding some stuff to my blog on this topic over the next month or so.
STATE OF THE INDUSTRY
The problem with the above is that third party cookies, such as those issued by Identity Providers, are often dropped by default these days due to browser security initiatives such as Intelligent Tracking Prevention changes - which is ON by default in Safari:
COOKIE PROPERTIES
Worth checking that your cookies are issued with SameSite=None, which will give you the best options for a third party cookie based solution.
MOBILE FIRST DESIGNS
In an OAuth world, in order to meet the requirements, it is likely to be necessary to send a token from the mobile UI to the web UI, which of course has prerequisites that need to be designed for:
Web UI must use tokens
Web UI must use different strategies for token handling depending on the host
OPTION 1
One option is to use a mobile web view to show the web content - see my code below:
Web UI Code to ask the host for tokens
Mobile UI Code to service these requests
OPTION 2
Another option is to send something representing the token in a query string parameter from the mobile app to the Web UI, in which case you need to ensure that:
No usable tokens are recorded in web server logs
The token has a one time use only
A typical implementation would look like this:
Mobile UI calls an /api/token/encrypt endpoint
API stores a token hash in a database and returns an encrypted value with a short time to live
Token is sent from the Mobile App to the Web UI
Web UI calls an /api/token/decrypt endpoint to get the real token
The API's decrypt implementation deletes the database entry
I am getting the following error when a request is send to the server. What does this message mean and how could I solve this.
p.a.m.DefaultUrlEncodedCookieDataCodec - Cookie failed message authentication check
I am trying to integrate Silhouette in my application. I am using cookie based authentication. I suppose the warning is related to it but I am not sure what it means and how to solve it.
You have to clear out the PLAY_SESSION cookie from the previous version of Play framework you were running. If you are using Chrome, go to Settings. Scroll down and click on Show Advanced Settings. Privacy -> Content Settings -> All cookies and site data. Here you have an option of clearing out all cookies or filtering by host (likely localhost if you are on your development machine) and deleting only the PLAY_SESSION cookie.
If done correctly, this warning will immediately stop showing up when you make a request to your server.
I switched to the iPhone user agent during which time I visited Google, then I changed back to the default Firefox one again. I cleared all of my history, cache and cookies but Google still thinks I am on a mobile device and insists on directing me to the mobile site. I have checked my user agent and it is definitely the correct one and I have removed every single cookie in Firefox.
How is Google remembering this information? Is there some other sort of mechanism apart from cookies that remembers user settings? It doesn't do it in any other browser.
I've seen some issues such as this on Firefox. Which add-on are you using to change the UA?
To be absolutely sure what the UA String you can Check you User Agent String
Also you can check for cookies using the Fire Cookie Add-On
Normally i can fix this issue by Closing the web browser and starting up a new instance of Firefox.
My other issue with Firefox is that it caches HTTP redirection rules from a website, so if i change a HTTP redirection rule on the server Firefox does not immediately pick this up - This problem is also fixed by closing the web browser.
I solved this problem in firefox by resetting my default agent:
Tools->Default User Agent->Default User Agent
and then going to:
Tools->Clear Recent History->Cache
Assume that you have complete programmatic control over a wireless router (running say OpenWrt or DD-WRT - linux). The router is configured to broadcast an ssid, and the network is wide open.
A mobile user (iPhone/Android/BB) walks up.
1) on iPhone, if the device is not currently wifi connected, a dialog appears that offers to connect to available SSIDs. The user picks my ssid and connects. Is there a way, from my router (say using Bonjour or ??) to trigger the iPhone to launch the web browser and try to load the home page, or an autoconfig url automatically?
2) any different answer for Android/BB?
The reason is that in a 'walled garden' application I need to be able to pop up a greeting page and don't want the user to have to fumble around loading a default page first.
Any and all thoughts appreciated!
Thanks
RM.
Update - I think the answer may lie in either 802.21 or UMA. I read somewhere that ATT uses this with iPhones for authentication.
On iPhone there is a switch called 'autologin' when connecting to a wifi gateway. If you turn that on, the iPhone sends an HTTP request, and receives a redirect from my hotspot, and then I send the welcome page. (the spot is totally open). Problem is that iPhone seems to be waiting for something specific - it doesn't change from '3G' to wifi and may eventually time out. Also it still displays the 'Login' banner docked to the top of the window.
Anyone know of documentation for the frames I need to send to do a proper autologin?
What you're describing is a captive portal system (hotspot, walled garden, etc). This functionality can be implemented with several application on openwrt. Check out another answer for details on each specific option offered in openwrt Answer.
There are a few common techniques to implement a captive portal
HTTP 302 Redirect
The most common technique is to simply block all out bound traffic on the network and then redirect any port 80 traffic to your own portal page, either local or remotely hosted. This portal page would then provide the means to "authenticate" the user (by poking a hole in the firewall). There are layer 2 methods such as chillispot which provide all the same functionality and can be authenticated against a radius server if you wanted to get fancy.
DNS Rewrite
Another technique is to use dns rules to rewrite any dns query to resolve to your own webserver which will then present the user with a login page, once the user has "authenticated" you simply updates their dns, or allow the dns request from that user to pass upstream.
IP Redirect
This technique often times overlaps a bit with the HTTP redirect. Essentially you redirect their requests to a new destination IP. You could setup a squid proxy to then handle these requests.
Both iOS and android devices will detect for captive portals by simply checking for a standard URI resource (eg: http://www.apple.com/library/test/success.html) and if that resource is blocked then you're offline, if that resource gets 302 or 307 redirected then it assumes there is a captive portal in place and they will open a browser. If that resource is found then they assume you are online and no browser is auto opened.
Android will open the standard browser on the phone or tablet to allow the user to authenticate. iOS devices will however open a pseudo browser which is a limited application which doesn't allow things like video playback popups etc.
The WISPr protocol I believe was originally intended for devices which do not have a web browser to accept the terms and conditions and thus allowing these devices a generic protocol to accept and authenticate against a captive portal. I'm not even sure that the WISPr protocol was ever really accepted. (perhaps they redrafted it)
(Didn't realize how old this originally was, sorry)
Ok, solved it.
The protocol is called WISPr - now version 2.0
some links
http://erratasec.blogspot.com/2010/09/apples-secret-wispr-request.html
and traces
http://coova.org/node/4346
HTTP 302 Redirect
The most common technique is to simply block all out bound traffic on the network and then redirect any port 80 traffic to your own portal page, either local or remotely hosted. This portal page would then provide the means to "authenticate" the user (by poking a hole in the firewall). There are layer 2 methods such as chillispot which provide all the same functionality and can be authenticated against a radius server if you wanted to get fancy.
// Working on creating a wifi Hotspot, which would automatically trigger mobile browsers(directly to my shop's link) when the mobile device is connected to the wifi.. This would serve as an interesting factor to user's, get noticed something special about our Hotspot when they cross across it..
I think what you're looking for is the ability to create a standard wifi "hotspot".
There are several very good tutorials online about how to do this, several using DD-WRT.
For example, check out this one: http://www.hotspotsystem.com/en/hotspot/install_guide.html
which gives some examples.
I'm looking for a solution similar to the iPhone Facebook Connect (https://github.com/facebook/facebook-ios-sdk) for the BlackBerry platform. Basically, I need my users to authenticate against Facebook from within a native BlackBerry application (so, not a Web based mobile application). Is there a library I could use, and if not, what will be the correct approach to achieve this?
Thanks in advance!
Options for BlackBerry are:
Use Facebook Platform for Mobile
Use REST API approach provided by Eki Y. Baskoro
Try to port JavaFB from J2SE to J2ME
I managed to go through Facebook Connect authentication within my BB app. After cracking my head for three days I realised that it is the URL that is the culprit!
Basically these are what you need (assuming you are developing for 4.5 platform):
Using Browser Field, do a POST to http://m.facebook.com/login.php (the mobile version of Facebook) passing all the necessary arguments as per the Desktop application counterparts (one challenge is to get the signature generation correct).
Once the User successfully grants access, capture the URL of the success screen. You will obtain your auth_token.
Do a POST to the REST server to obtain the session key and secret given the auth_token you obtain.
Save the returned session key and secret, persist it, and wholla! your app is up and running.
I am developing a custom LoginScreen and FacebookFacade object to incorporate the first three steps above, if anyone is ever interested to reuse my code. It'll be GPLed, I suppose ;)
Afzal, I had a similar problem and I've found out that I actually had a problem with my connection string. You can look at the following link there is some explanation and code for creating the correct connection string
http://www.localytics.com/blog/post/how-to-reliably-establish-a-network-connection-on-any-blackberry-device/
and just add the connection string to the FetchThread where it opens the connection:
connection = (HttpConnection)Connector.open(absoluteUrl+getConnectionString());