In the docs on server response extras, I find this:
When network problems prevent or interrupt a license check, the Android Market client notifies the application by returning a "RETRY" response code to the Policy's processServerResponse() method. In the case of system problems, such as when the application is unable to bind with Android Market's ILicensingService implementation, the LicenseChecker library itself calls the Policy processServerResonse() method with a "RETRY" response code.
Unfortunately, RETRY is not listed one of the listed response codes that the server returns, and when I look at the LVL source code, it appears that the Android Market client actually returns one of the server response codes and it is the LicenseValidator class in the library that decides when to turn that into a RETRY response status.
Furthermore, in the section on implementing a custom policy, there's this in the guidelines:
Note that the Android Market client automatically retries failed requests, so in most cases there is no need for your Policy to retry them.
I find this confusing. Does the client simply report one of the documented server response codes, or does it do more? If the device is in airplane mode, for instance, does a custom policy need to deal with RETRY or with ERROR_CONTACTING_SERVER? Should the policy (or application) deal with retries, or does the client do it automatically?
Related
I'm using the TRESTClient, TRESTRequest, TRESTResponse component stack for communication with the https REST API service. The Server authenticates the client by sending the request using the client certificate.
In my Android application, after calling the RestRequest.Execute (rmPost) method, a form appears asking for the selection of the client certificate. I would like to automatically assign a client certificate and avoid this additional question, but the RESTClient.OnNeedClientCertificate event is not fired.
I checked RESTLibrary, and I separately checked TNetHttpClient (the event OnNeedClientCertificate is also not fired), after several hours of reading blogs and performing dozen of tests, I am so frustrated as I have no idea how to solve the problem.
How can I avoid this additional question about choosing a client certificate and set the client certificate automatically?
Why is the TRESTClient.OnNeedClientCertificate event is not fired?
Thank you for any suggestions and help.
I am developing Android native application integrated with IBM MobileFirst backend.
I have issue with some operations that required custom authentication with predefined realm for example ("testAuthRealm")
and when I call any operation that requires authentication and user is not authentication it is returning a response with some details:
WL version: 7.1
Anyway, I can detect from the response that the user is not authenticated
but I think this is not a good way to check authentication.
my inquiry:
is there any supported method from the MF SDK to check user authorization for realm?
is that good to check authorization from the response?
advise please
If you request a protected resource, the server response will contain the authorization status required ( based on your custom authenticator implementation). This server response would kick off the challenge handling procedure in your client application. This is by design. Refer to Custom Authentication documentation. This way you need not separately check for the authorization status yourselves and then try to login.
Is there any supported method from the MF SDK to check user authorization for realm?
You can consider one of the following APIs in the client SDK:
a) isAuthorizationRequired
b) getUserIdentity
c) getLoginName
d) getUserName
Is that good to check authorization from the response?
Challenge handling at the client will depend on the status of authorization(from the server response). Based on this status, you either handle the challenge or allow access. So, you need to check and verify the server response to complete the authentication flow.
While running UI Espesso tests I would like to also verify if the app is making correct http requests (e.g triggered by a button press). Currently using OkHttpClient client to make the requests.
Did you try something? I like to use Wiremock to mock http requests and check that the app have done the correct request. You must use the standalone version or you will get some issues with HttpClient.
For more information see http://wiremock.org/index.html
I am confronting myself with a problem that I do not know how to interpret. I am doing a project using Android and Google App Engine. When I am trying to save information in Google App Engine's Big Table, directly from the servlet (hardcoded) - the save is performed with no problem. But when I am trying to save data from my Android device, the save is not performed and the log indicates Apache-HttpClient/UNAVAILABLE error. To be more specific:
405 55ms 0kb Apache-HttpClient/UNAVAILABLE (java 1.4)
82.155.246.249 - - [10/Jun/2013:05:20:59 -0700] "POST /servletnamehere HTTP/1.1" 405 306 - "Apache-HttpClient/UNAVAILABLE (java 1.4)" "appnamehere.appspot.com" ms=56 cpu_ms=21 cpm_usd=0.000034 app_engine_release=1.8.0 instance=00c61b117cede3f754aa1ece730dc88287a20199
I have seen that 405 HTTP error appears in the context of a POST method ( "405 errors often arise with the POST method. You may be trying to introduce some kind of input form on the Web site, but not all ISPs allow the POST method necessary to process the form." ) => indeed, I am trying to perform add (the object is a JPA Entity) in the database using a POST method. The data I am receiving from my Android device is serialized, through an input stream (in my case, working with JSON is not an option, these are the specifications).
Also, 306 HTTP error reffers to switch proxy. While the porevious error might be a bit intuitive, this one is beyond my student knowledge.
I have followed the instructions of this tutorial (http://trumpy.cs.elon.edu/joel/sigcse2011/), which is indeed what I need, but I really cannot figure out what I did wrong. I took again the procedure, stept by step, but I don't see the flaw.
Any help will be indeed appreciated. If I should post some code, I'll gladly do it.
Best wishes,
Cropcircles
LATER EDIT:
Now I get 417 HTTP error expectation failed. I have seen that I am supposed to set a certain parameter on false, but this workaround was available only for .NET. Is there anyone who knows what's the correspondent of the following, in Java? I am really really confused.
<system.net>
<settings>
<servicePointManager expect100Continue="false" />
</settings>
</system.net>
This is not an answer, but is too long for a comment and may be helpful, so here goes...
First, it's hard to tell what's going on here because there is limited info. Try to post more of the logging either on the client or on the server. Go to the server console and get more info, for instance, or add debugging in the client. I'd start by trying to make the POST from a debug/testing tool like hurl.it: http://www.hurl.it/ (hurl is a nice web front end to a command line HTTP client named curl, see curl itself if you want a more advanced peek). That way you can test and poke around and make SURE your server side works as you expect with a generic client. Then build other clients (like Android).
Second, "Apache-HttpClient/UNAVAILABLE" is not an error, it's just the user-agent String -- so ignore that part. (UNAVAILABLE is where the version typically is, but some impls don't have access to the version sometimes, it seems.)
Third, the 405 response code IS an error, it means POST is not allowed at the server you are trying to POST to. That can either be because POST is not allowed at all on said server, or you're violating some security policy (such as same origin).
If it's AppEngine, first check the APP you are using and make sure it supports POST (look for info on how to do POST at AppEngine to solve, for instance: google app engine: 405 method not allowed). When you say you can do it directly from a "servlet," do you mean that a POST from a different client works? (Servlet is a server side technology, so that's a little confusing.) If so then make sure your Android app is doing the client part the same way to the same host (multipart vs urlencoded, etc).
For a little more on the security stuff, which could be involved, see this post: Google App Engine + jQuery Ajax = 405 Method Not Allowed.
I've had the same trouble and in my case It was an error due to no write permission on server side area.
I was following an android test to write on a file a value transmitted in async way via POST method.
Apache received the POST request but was not able to write the data on the file due to security permission on it.
I am trying to set up an Android app where I can access URL's behind arbitrary proxies or HTTP authentications. That is, the app won't know immediately if a URL needs authentication and will repond to an authentication request by asking the user for credentials, the same way it does for the Android Browser.
I recently worked out how to request user authentication for a WebView, responding to authentication requests from the browser, bringing up a dialog, and advancing the user to the destination page. I am looking to do the same with HttpClient.
The basic process, as I see it, is to:
Perform the request via HttpClient.execute.
If not 401 or 407 with proper headers, trigger a "done" callback.
Otherwise...
Pop up a dialog asking for the username and password.
Set the http credentials in the HTTP client via HttpClient.getCredentialsProvider().setCredentials.
Return to step 1 until the the user clicks cancel or the server gives up. In that case, trigger a "failed" callback with the last response received.
Am I on the right track or has someone already implemented something similar? I would hate to be reinventing the wheel on this.
You should try the authentication example on the apache site
httpclient.getCredentialsProvider().setCredentials(
new AuthScope("localhost", 443),
new UsernamePasswordCredentials("username", "password"));
The direct link to the java file is http://hc.apache.org/httpcomponents-client-ga/httpclient/examples/org/apache/http/examples/client/ClientAuthentication.java
The reactive approach described above did work. Responding to an arbitrary 401 or 407 request is effective with the caveat that you need to suppor each authentication scheme you expect to encounter so something like UsernamePasswordCredentials won't work for NTLM.