Utils.getHTTPClient ignores trustAll parameter

[GoogleCodeExporter]

It seems like the trustAll functionality is currently broken. I just verified 
that the correct setting is passed into the API call, but my users still report 
that they get the invalid SSL certificate error (see #600). Also, the function 
right now leaks login credentials, etc. to logcat because it prints POST data.

Original issue reported on code.google.com by sca...@gmail.com on 1 Nov 2011 at 11:24

[GoogleCodeExporter]

i can't find any problems in the api's code, which is very strange.

Log.d() calls are meant to be removed before releasing to improve performance. 
the shell scripts in ub0rlib/shell can do that for you. i removed the lines 
anyway.

Original comment by f...@ub0r.de on 6 Nov 2011 at 1:30

• Added labels: Component-Persistence, Product-WebSMS

[GoogleCodeExporter]

Thanks a lot. Is there any way to make Eclipse auto execute the shell
scripts before exporting? Probably will break Windows builds... Android
logging sucks.

Original comment by sca...@gmail.com on 6 Nov 2011 at 2:31

[GoogleCodeExporter]

well, i never used the export method of the adt plugin. i just build the
final apk with ant myself ;)

Original comment by f...@ub0r.de on 6 Nov 2011 at 2:36

[GoogleCodeExporter]

This seems interesting:
http://stackoverflow.com/questions/2018263/android-logging especially
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/and
roid/2.2_r1.1/com/android/internal/logging/AndroidHandler.javawhich
seems to only print enabled "verbosity" levels. Maybe this is an
option for the WebSMS Logging API.

2011/11/6 Lorenz Bauer <scahoo@gmail.com>

Original comment by sca...@gmail.com on 6 Nov 2011 at 2:37

[GoogleCodeExporter]

Haha, lazy me ;)

Original comment by sca...@gmail.com on 6 Nov 2011 at 2:38

[GoogleCodeExporter]

The problem is that the httpClient is cached by Utils.getHttpClient after its 
created for the first time. So as long as websms "runs" in the background as a 
cached process, any change of the trustAll-parameter in the settings are ignore 
because no new httpClient is created after that.

As the caching is a good thing and even seems to be used for some 
cookie-handling, I did not change this behaviour but added a resetHttpClient() 
which can be called by a connector after a significant settings-change.

However I don't think this is a very nice way of handling with this because the 
connectors need to be aware of this when using the websms-api...

Changeset and pull-request for websms-api:
https://github.com/Boris-de/websms-api/commit/0956b059f
https://github.com/felixb/websms-api/pull/3

Usage in connector-o2
https://github.com/Boris-de/websms-connector-o2/commit/a0609cc95

Original comment by boris-c...@gmx.com on 13 Nov 2011 at 9:01

[GoogleCodeExporter]

Yeah, I'm feeling the same way. HttpClients should have to be instantiated and 
cached by the connector. Right now, there is too much "magic" in Utils. I have 
done some preliminary work in that direction, unfortunately I don't have time 
right now to pursue it any further.

Some things one needs to think about:
* How long is the lifetime of a WebSMS Connector process? I had some discussion 
with Felix here, but my own tests indicate that there is no guaranteed 
lifetime, even for static variables. Android destroys and creates processes 
based on memory pressure and other factors, methinks.
* This means that cached login information (in the form of cookies, etc.) might 
not survive very long, which creates additional overhead when sending sms / 
checking balances. There really should be an API construct to persist certain 
information, with provisions for expiring it appropriately.
* Tied into this issue are certain limitations within the connector API. For 
example, my O2 connector would need to reset login information if the default 
WebSMS sender changes. AFAIK, this has to be worked around in updateSpec, which 
again means that the code runs way too often. Ideally there would be a way to 
be notified of certain changes in main WebSMS settings.

Sorry to dump all this in here, but as it stands I currently do not have the 
time to implement any of this. As it is, we need Felix's input on this. Maybe 
we should open a new Issue. Felix, what are your thoughts? Boris, any more 
comments?

Regards,
Lorenz

Original comment by sca...@gmail.com on 14 Nov 2011 at 10:58

[GoogleCodeExporter]

> How long is the lifetime of a WebSMS Connector process

Seems to vary on different factors. Seems to be a very long time on my device, 
but this is nothing you can rely on as the system may kill any old process when 
it feels the need.

Persisting the cookies should be easy. The Utils already support using your own 
list of cookies. But this leaves the application with the problem to close the 
session / logout the user after a reasonable amount of time. AlarmManager seems 
to offer that (running an intent after an amount of time).

Boris

Original comment by boris-c...@gmx.com on 14 Nov 2011 at 9:04

[GoogleCodeExporter]

i just merged boris' changes to the api to let you implement his workaround.

regarding api magic:
feel free to no use the api or add a second method to do http traffic.
it's meant to be useful for most connectors, not for all.
the o2 connector with no api available is some kind of stranger in the family ;)

regarding lifetime:
boris is right. nobody can say, how long the connector stays in the memory.
on my g1, it is mostly kicked out before it finished sending.
on my g2/tf, it can last for days.
but the o2 connector does have a larger memory footprint and may get kicked out 
earlier.

Original comment by f...@ub0r.de on 18 Nov 2011 at 6:32