Hello every professional,
I'm a new in Android development, recently, I just get into Android area, now I encountered a problem when I tried to access server application with HTTPS request (Like https://DEVELOPMENT_SAMPLE.com/project), we use Spring for Android to handle request, and use ApacheHTTP Server + Tomcat + SSL` as a deployment environment. When I use HTTP request instead of HTTPS request and remove SSL from the deployement environment, the access can be successfully handled. I share the related code from here:
RestTemplate restTemplate = new RestTemplate();
restTemplate.getMessageConverters().add(new GsonHttpMessageConverter());
restTemplate.getMessageConverters().add(new StringHttpMessageConverter());
HttpComponentsClientHttpRequestFactory factory = new
HttpComponentsClientHttpRequestFactory();
factory.setConnectTimeout(1000 * 15);
restTemplate.setRequestFactory(factory);
I know There are two native HTTP clients available on Android, the standard J2SE facilities, and the HttpComponents HttpClient. The standard JS2SE facilities are made available through the SimpleClientHttpRequestFactory, while the HttpClient is made available through the HttpComponentsClientHttpRequestFactory. The default ClientHttpRequestFactory used when you create a new RestTemplate instance differs based on the version of Android on which your application is running.
But the question I want to ask is how to make my HTTPS is available for Android client? I guess some change should be made in getting Connection object.
Thanks so much.
Yes, Android can communicate with HTTPS. Read this link:
Accepting a certificate for HTTPS on Android
See also this excellent article:
Making Android SSL Work Correctly
Related
I'm newbie in development and I have to develop android sdk. It's going to wrap network API and provide OAuth 2.0 authentication functionality. Also web sockets for session ending and push notifications will be included in sdk. I'm planning to use Facade design pattern:
public interface SdkFacadeInterface {
AuthenticateRequest authenticate(); // http request
StartCallRequest starCall(); // http request with establishing websocket connection, push notification sending
SelectGatewayRequest selectGateway(); //http request
EndCall endCall(); // http request called after web sockets connection closes
HistoryRequest getHistory(); // http request
void setFirebaseToken(Context context, String firebaseToken);
interface Builder {
Builder setCliendId(String cliendId);
Builder setClientSecret(String clientSecret);
Builder enablePushNotifications(booleanenablePushNotifications);
Session build();
}
}
After authentication I need to save refresh token and access tocken to the phone storage, I'am planning to use SharedPrefs for it. I have the following questions:
What architecture should I use? Is there some architectural patterns for sdks which I can use
Maybe you know some sdk on github which I can use as reference for my project.
Can I use retrofit for http request or I rather use AsynTask with HttpUrlConnection so my sdk will have as little external dependencies as possible
Sdk development is different from applications development, what should I take in consideration for developing sdk(all suggestions and ideas a welcomed)
How should I handle bad input from clients, should I throw exception or just write error to logs (Log.e(..))
Thanks in advance
I'm using loopj to make http requests in my android app. I've recently added new relic and so far I don't see any of my app's http requests showing up in the dashboard. I do see other data streaming through new relic, but nothing on http requests.
Does newrelic even support http requests made with loopj or is there something special I need to do in order for it to work?
It looks like this library requires the apache library directly. Currently New Relic does not instrument org.http.apache. If this is something you want to see New Relic do you will want to open a ticket with them at support.newrelic.com and request a feature request.
I am using Spring for Android in a project and I need to manage the cookie store/manager. I am able to add cookies to any request by using an implementation of ClientHttpRequestInterceptor, but I would like to remove some of these when sending a request.
To be more specific, the problem I am facing is that, for Froyo, the implementation specific in Spring (with DefaultHttpClient) adds automatically to headers the cookies from CookieStore - that even if I am setting explicitly the headers. But I would like to manage these cookies myself (either remove some of them, or update their values). While for Gingerbread above (Spring implementation is done with HttpURLConnection) the cookies are added only if I am doing it myself - however I am not that sure as I don't see Spring setting any CookieHandler, but the bottom line is that I don't see them when performing a request or I can see them updated. So the issue is more specific to Froyo.
The work-around is to reset the connection factory; something like:
protected void resetCookieStoreForTemplate(RestTemplate template) {
if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.FROYO) {
template.setRequestFactory(new HttpComponentsClientHttpRequestFactory());
}
}
Underneath, that seems to recreate the DefaultHttpClient and will use a new CookieStore. But that seems to me a bit ugly.
To wrap up, my question would be: does Spring for Android provide some method to expose some API for Cookie management? Just the way RestTemplate exposes some abstractions for connectivity, connection factory, message converters and so on, I would be very happy to have some abstraction for cookie management.
I've not used Spring myself but from what I've read about it, it follows the official advice and switches HTTP clients based on API version (which is quite clever, if seriously over-engineered for my liking). When using HTTPUrlConnection, as you mentioned, Spring probably doesn't change the CookieHandler. You should be seeing in-memory cookie handling, so everything should work for requests in the same app run but the cookies would be wiped when you close the app. Can you confirm this is what you're seeing?
If so, all you have to do is create a new CookieManager instance, passing it a custom CookieStore and null for the CookiePolicy to use the default.
It's unfortunate that a persistent store isn't built-in but it's not particularly difficult to write one either.
Edit: See here for a CookieStore that uses SharedPreferences (haven't tested it myself).
The ClientHttpRequestInterceptor class is a good approach when you need to pass common headers for all requests such as setting up content type, authorization etc. As far as I understood you want to pass some cookie values for specific request.
You could also achieve this via HttpEntity and HttpHeaders class.
HttpHeaders requestHeaders = new HttpHeaders();
requestHeaders.add("Cookie", "name=" + value);
HttpEntity requestEntity = new HttpEntity(null, requestHeaders);
ResponseEntity response = restTemplate.exchange(
"http://server/service?...",
HttpMethod.GET,
requestEntity,
Response.class);
Spring rest template does not provide any off the self solution for managing cookies. The class CookieHandler is provided by Apache not part of spring. Rest template is just a basic solution for managing request response with compare to spring core.
I'm trying to implement a RESTful web service using Spring. I've set up Spring Security to work on the links that apply to the REST service. I make calls to this web service from an Android application. What I've done now is connect to it using Basic Authentication. What I'm struggling with is finding decent information about how secure this really is. I figure I should at least be making these calls through SSL or something no?
My code on the Android client that calls the REST client
public MyClass callRest() {
final String url = "http://10.0.2.2:8080/myservice/rest/getSomething";
HttpAuthentication authHeader = new HttpBasicAuthentication(username,
password);
HttpHeaders requestHeaders = new HttpHeaders();
requestHeaders.setAuthorization(authHeader);
requestHeaders.setAccept(Collections
.singletonList(MediaType.APPLICATION_JSON));
RestTemplate restTemplate = new RestTemplate();
restTemplate.getMessageConverters().add(
new MappingJacksonHttpMessageConverter());
try {
ResponseEntity<MyClass> response = restTemplate.exchange(url,
HttpMethod.GET, new HttpEntity<Object>(requestHeaders),
MyClass.class);
return response.getBody();
} catch (HttpClientErrorException e) {
return new MyClass();
}
}
So what I've put in my Spring Security config right now:
<http auto-config='true'>
<intercept-url pattern="/rest/**" access="ROLE_USER"
requires-channel="https" />
</http>
I can't figure out where to go from there, because now the connection doesn't work anymore of course because of the https. I can't seem to find decent examples of how to figure this out using the Resttemplate.
Any help?
HTTP Basic Authentication is reasonably safe when used over HTTPS since the user and password fields are sent over an encrypted connection so they are much less vulnerable to man-in-the-middle attacks. There are some interesting points here: Securing an API: SSL & HTTP Basic Authentication vs Signature
In my opinion, if you are making a API with access to user's sensitive data (i.e. bank account details, credit card numbers, email addresses and passwords) then you may want a more secure approach because HTTP Basic Authentication is succeptible to brute force attacks as it is always available (unless you build in deterrents such as maximum retries etc.) If your API is for a game or basic business data then there should be less attraction for a hacker to spend the time on it.
Does your server support HTTPS - often you need to pay extra for a HTTPS certificate or you have to use a shared once which give you a subdomain on a shared HTTPS domain - i.e. https//your-site.your-hosting-provider.com/. You need to check this perhaps.
UPDATE 1: Your problem appears to be with your server and not with your program. Check out this blog post for information about how to set up HTTPS on your Tomcat Server. You need to do this before you can use HTTPS from your Spring application - looking at your code, there doesn't seem to be a problem other than your server.
Also try this.
UPDATE 2 Once you have access, you will then need to trust the certificate on the Android device (or your Java installation if you were making a desktop/web application). It needs to be trusted because you created it yourself rather than a CA authority. See this answer: Trusting all certificates using HttpClient over HTTPS (Not the part about trusting all certificates - this can be dangerous).
So basically i need my android app to connect to a web service using a url as such
"http://username:password#0.0.0.0" aka basic authentication.
obviously the username and password are checked by the web app before allowing access and otherwise doesn't allow the request.
my issue is that all the methods i try always say unauthorised (response code 401) regardless of what combination of classes and methods ive used to try and connect to the the url.
The web app in question is designed to return things only is un/pw clears otherwise it returns nothing, the web app and un/pw etc have all be checked and cleared.
so does anyone no the correct way to send a request to a url like that and have it work correctly?
android api8 btw
UPDATE
Turns out my issue is due to the web app using NTLM windows authentication which is not supported directly by androids/apache http library, investigating appropriate workarounds now
Here's some code form a really old project of mine. I used basic auth for some web service, and this worked at the time. I'm not sure if there are updated api's since then (this was Android 1.6), but it should still work.
HttpGet request = new HttpGet();
request.setURI(new URI(url));
UsernamePasswordCredentials credentials =
new UsernamePasswordCredentials(authUser, authPass);
BasicScheme scheme = new BasicScheme();
Header authorizationHeader = scheme.authenticate(credentials, request);
request.addHeader(authorizationHeader);
Basically, Basic HTTP auth is a simple hash of the user and password. The browser allows you to stuff these values in the url, but it actually does the work of adding the basic auth header to your request.