We have built an Android app which uses Firebase for user authentication. Our (large enterprise) client is planning to deploy it behind their firewall. During initial testing, the authentication stage fails whenever we are using their network. It does work on an open network.
I am trying to find out what firewall configuration is needed to use the firebase authentication API, but I cannot find anything in the docs. I know that the firewall allows port 80 and 443 for outgoing connections. I am assuming that no specific IPs are blacklisted. Ports 5228-5230 (which would be required for FCM) are not opened yet, as we are currently not using push notifications. I am wondering if this is the issue. However, all references I can find (usually inofficial ones on stackoverflow) insist that the firebase authentification happens via https and only 443 should be needed.
Is anyone able to verify this and perhaps provide the documentation which details this?
I'm trying to connect to a VPN, in order to have permissions to some web services that I request using HttpURLConnection. I need to enter the server and the credentials to the VPN, but I have no clue how to do that. I'm concerned that exists the vpnService but I didn't find how to use it and mainly how to pass credentials to it. Can you guys help me?
I want to establish the connection to a VPN from my university and, once did it, make the connections pass through it. I did it manually at the phone and It worked. Now I want to do it at the code so people that uses my app don't need to do that.
Edit: I just want to connect to a vpn programatically, instead of doing it through the vpn settings at android's settings menu.
I am looking for an existing library to establish a connection between any smartphone(android/ios/win phone) and a web page.
Sort of what whatsapp is using (https://web.whatsapp.com/), with authentication.
Once the connection is established, i will have to send real time data ( audio and text) from the phone to the pc.
I suppose that whatsApp use a server to relay the data. i dont mind doing the authentication with the help of a server but once the connection is ok,I prefer to do all the communication on wifi instead of sending data from the phone to a server and sending it back to the web page on the pc.
Thanks!
When you want to solve a particular problem which is already solved, You don't want to reinvent the wheel(especially in web) but use the existing solution.
What you are looking for is WebRTC. Fits exactly for your use case. But i am not sure about the development efforts required for this.
There are Client libraries in almost all languages. A quick search gave this for Android
And i am not sure about the device support you are expecting, check Caniuse?
Also have a look at WiFi-p2p for android.
UPDATE:
check this webrtc website for cross platform development support and examples.
There is no real "best" way of doing this, but you have to have a server of some type running on your computer. From there you can use normal network requests from Android to communicate with your computer as long as they are on the same network (WiFi). https://developer.android.com/training/basics/network-ops/connecting.html
Some users complained about network issues.
Our android app communicates to our server through https.
Our Apache logs showed responses with the status; "405 Method not allowed (CONNECT)", this problem was only reproduced on specific IP addresses.
I don't understand why the android app is trying to reach the server with a CONNECT method, I never use this method in the app, I use only GET, POST or PUT.
It seems a proxy may be involved in that problem, but I have no idea how to solve it. Does anyone know ?
Looking at the wiki for http connect
A variation of HTTP tunneling when behind an HTTP Proxy Server is to
use the "CONNECT" HTTP method.[1][2]
Not to point out the obvious, but enabling the connect method in Apache seams like the answer. Easier than asking the customers to remove their proxy servers.
You need to provide support for the CONNECT HTTP method, which is commonly used to tunnel SSL requests through proxy servers. Thats why you are receiving them, some users are behind a proxy.
In Apache, to enable handling CONNECT requests, mod_proxy and mod_proxy_connect have to be present in the server.
The problem is that you need to secure your server, which will probably defeat the purpose of you app.
DON'T enable mod_proxy and mod_proxy_connect if you have not secured your server.
I cannot provide a turn-key solution, as half the battle here is in the source tree for your supported Android application, as well as a combination of variables pertaining to your employer's infrastructure policies. You have three big questions to answer, and should conceptually do this for every problem brought to you as the Apache administrator:
When were the "problem" clients last able to connect without issue?
What changed between then and now, and when did it change?
Do CONNECT messages correlate 1:1 with clients reporting errors?
Questions one and two are priority, but should not be discussed in depth on a public forum like this. Changes made to your public or private configurations, applications, etc., are often considered the intellectual property of your employer. Use caution if you discuss that here or anywhere. If you find that changes were made, even "harmless" changes, discover their correlation to the customer issue and implement regression testing where applicable.
Question number three is what I will discuss. Based on the messages I've read above, it is not confirmed that CONNECT correlates to every customer issue. It seems as though some customers reported issues, and you looked at logs for symptoms of a problem. The CONNECT errors look like a problem, and based on some of the Android app spec you've shared, they might be the problem. However, they might also be "log noise" generated by someone scanning your server for vulnerable modules.
If you have not yet proven the correlation of CONNECT to customer error, try using the <If> directive and logging additional data about clients who issue CONNECT statements. As a generic example:
<If "%{REQUEST_METHOD} == CONNECT">
... some extra log format fields to get ALL of the data ...
... maybe a special log file just for CONNECTers?
</If>
Use the gathered data to understand a trend. It might be that only specific versions of Android with your app are behaving this way. You can branch <If> to change the way those users receive content, or you can work with the developer of your Android app (the current one, or the next one you hire ;) ) to develop a list of web server requirements based on the app, itself.
Better still, a well-constructed block can enable you capture debug data for specific clients without disrupting those whose apps work. As always, I recommend building and testing in a lab first; never deploy brand new ideas to production, and most certainly never enable modules because the Internet told you to, even if they were right in naming the module.
Here are links to Apache's documentation for the <If> directive:
http://httpd.apache.org/docs/2.4/mod/core.html#if
http://httpd.apache.org/docs/2.4/expr.html
Good luck!
I have a backend server, and want to provide an SDK for connecting to that backend server. The sdk is going to be built for iOS and Android and will ship as a library separate for those platforms.
The problem is I want to make sure that the requests are sent only using the sdk that I provide. Basically everybody knows that it is possible to monitor WEB requests using proxy applications like Fiddler or Charles proxy. And it is possible to usurp the requests and send those requests manually as many times as one wants.
For my scenario should be made impossible. So I need a way to identify in the backend that the request that I've received is for sure sent from my sdk. How can I achieve this?
EDIT1:
I can guess something like digipasses may be used. For instance when I log into my bank account I get one time password and log in. But that is based on time, and I can not count on the time of device. May be we can reuse the concept.
Thanks for answers!