We have a mobile app that calls endpoints on host https://www.currentdomain.com. we are migrating to https://www.newdomain.com in a month
The network team is planning to setup a dns redirect from currentdomain to newdomain.
What is the best possible way to handle this change in the app with minimal change and work? What will happen if the app calls the endpoint on currentdomain after setting up the dns redirect?
You can support redirection in your APIs.I am not sure how much is it possible at your end but if yes, then no changes will be required at app side.
Otherwise http redirection can be handled easily by apps, like in iOS 1 method needs to be added & can redirect request to the desired url.
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/URLLoadingSystem/Articles/RequestChanges.html
Redirect handler in android
https://developer.android.com/reference/org/apache/http/client/RedirectHandler.html
Related
I'm developing an Android application, it is like a browser, has a web-view and sends http(s) requests. For debugging purpose, I want to be able to see the requests sent and received by the application (in particular the headers), but I'm unable to do so.
What i tried
I mainly debug the app with Chrome on PC, and use the Network Inspector in Chrome. The problem is that my app uses the ShouldInterceptRequest to intercept the requests an then manually sends a request with cronet. Chrome, in this case, shows some "provisional headers" that are from the original request, an not the headers of the actual request i sent manually.
I tried to use Fiddler and HTTP Toolkit, but the server I'm communicating with, doesn't like the certificate they use, so they can monitor correctly, but, if active, i cannot reach the page i need to monitor.
I also tried the Android Studio network inspector, but seems it work only for HttpURLConnection and Okhttp(1)
Thanks for your time.
If you're using a WebView, set a custom WebViewClient and override shouldInterceptRequest. That will pass in a WebResourceRequest object that will include all headers.
The issue I'm facing now is related to poloniex public API. For some reason I get the error on web browser on ask reCAPTCHA option.
[3463] BasicNetwork.performRequest: Unexpected response code 403 for https://poloniex.com/public?command=returnChartData¤cyPair=BTC_XMR&start=1405699200&end=9999999999&period=14400
In theorie, API methods are call from a code ( and not directly as a normal webpage on a web browser.)
When you write code to make api call, generaly (except a specific requirement ) you did not setup the "User-Agent".
In your case the User Agent is added on your web browser side.
So it is possible that Poloniex double check "User-Agent" in order to ban not conventional browser ... probably to avoid DDOS.
Last news has confirmed that some fake poloniex android app was stealing API secret and key, so it is potentialy a security feature setup in response to this treat by Poloniex to avoid definitly that "malware" android app could act on wallet without the user permission.
If it is not relative to anti-ddos process it could be relative to mobile ISP applying filter or doing MIM for security.
I am currently working on implementing a mobile app for our site that uses Ruby on Rails and Devise. The idea here is, at first, create a mobile login form that on successful login opens a web frame that is authenticated and allows the normal use of the (mobile optimised) site. Theoretically that should be possible.
I am having trouble with the following issues:
How do you get the pure session key for the user session via a json request? What methods can be used to manually generate it from devise, something that the sign_in(:user, user) method does?
Is it even possible to take that key and put it into the browser cookie the way it normally happens in devise, but on the mobile side?
I know that this is not the standard method of making mobile applications for the site, but I believe it should be possible.
You might want to consider using Devise Token Auth and treating your mobile application like just another webapp that requests permission from your main site. DTA is particularly nice since it takes care of managing the session tokens (renewing/expiring) and passing them onto the app requiring access. The issue is overriding your session controllers so that it automatically logs in after you already log in on the mobile app (or just rewriting your log in so it occurs in conjunction with the Rails site, rather than before). Considering you're already using Devise, this may also be more refactoring than you'd like.
If you want to put your authentication form on the mobile UI and pass the credentials over to the web frame, you need a way to pass data from the mobile app to the web frame.
How you accomplish this depends on what platform you're building on. I'm not really a mobile developer so I don't know for certain how difficult / easy these options are:
When opening the web frame, instantiate it with session data
Find a way to call methods on the client from the web frame. Something like getSessionData.
You could generate a fingerprint for the web frame, have the mobile UI send this data to the server, and then have the web frame authenticate with the server by sending the fingerprint.
Again, I'm not entirely sure how possible all these options are.
You should use token authorization and Android deep linking. It will allow you to login in the web browser and send a token to your app via deep linking.
OK, so I decided to make a webframe solution as follows, basically you post the login and password to a certain sign_in method specially designed to generate one-time sign in tokens for the application. You need two methods in the system to do that:
routes.rb
devise_scope :user do
get "sign_in_with_token/:token" => "sessions#sign_in_with_token"
post "get_login_token" => "sessions#get_login_token"
end
sessions_controller.rb (don't forget to add the method that increases the failed_sign_in_count on wrong password, otherwise that can allow brute force attacks)
def get_login_token
user = User.find_by_email(sign_in_params["login"])
password = sign_in_params["password"]
if user and user.valid_password?(password)
token = SecureRandom.hex(16)
user.update_attribute(:authentication_token, token)
render json: {token: token}, status: 200
else
render json: {error: "error"}, status: 403
end
end
and the method to sign in with that token
def sign_in_with_token
#user = User.where(authentication_token: params[:token], email: Base64.decode64(params[:email])).first
if #user
#user.update_attribute(:authentication_token, nil)
sign_in(#user, bypass: true)
end
redirect_to '/' # or user_root_url
end
That way the mobile app will work like this:
use the generic web frame to send ajax requests to the server and get that token for the user email if password is correct.
make a /sign_in_with_token/#{token from ajax}?email=#{base46 encoded email} link inside the app.
open that link inside the web frame and use the app as though you were logged in normally. Now the app can save email and password locally and use that logic to get the token again for another session. Later logging in will also be able to set the app id so that push notifications can be sent.
Appreciate any feedback or criticism on this solution.
My friend implemented an HTTP POST request in iOS and it was working fine.
I have tried to implement the same in Android, but it doesn't work until I added the User Agent (I got it with the help of some sniffer tools).
But in iOS he is not specifying the User Agent.
So,
What is the relevance of User Agent in HTTP Request?
Why is it not consistent between iOS and Android?
iOS already specifies the User Agent by default. The user agent sent with NSURLConnection on iOS is
User-Agent: <app identifier>/<app version> CFNetwork/609.1.4 Darwin/12.4.0
where <app identifier> is your bundle ID (e.g. com.company.app) and <app version> is the current version of your app. Apparently, as you experience, Android does not set a default User Agent with (non-browser) HTTP requests.
The server can use this information to adapt its response to the client's needs; e.g. showing a mobile version of a webpage instead of a desktop version, or just don't return anything (to prevent simple screen scraping).
A sample mobile application sends POST requests to a HTTP server which we use to process information sent from the mobile application. We parse HTTP headers and the User-Agent header is always seen as "Apache-HttpClient" on all Android devices with different OSes.
If i perform any action from app in android device, it returns the user agent as Apache-HttpClient/UNAVAILABLE (java 1.4)
what's the problem? It doesn't provide me a User Agent string which contains information like OS information and other details.. Has anyone seen similar behavior before?
Apache-HttpClient/UNAVAILABLE (java 1.4)
Is the default User Agent string for the Apache client that your app is using, it is not an error in itself.
This client know's very little about the system that it is running on, which is for the best - it's just a simple one-size-fits-all method for an Android device (which could be a phone, a tablet, a TV or even a car!) to make http requests to the outside world.
User Agent strings are a way for User Agents (read "browsers") to identify themselves.
In the case of an Android App, your App is the browser, so the User agent string is for you to define within your app.
See: Android Generic User Agent (UA)
If you want to send information about the device then you need to collect that information with your app and then send it. Though, if you are collecting that data then you might as well put it in the body of the request rather than HTTP headers anyway.