04-20-2011 12:48 PM
I'm developing a client application which uses the REST API of the corresponding server application, which is build by our company.
We are targeting devices with system software 4.5 and up, although we may drop support for 4.5 in the near future and making 4.6 the new lower limit. Currently, dropping support for anything below 5.0 altogether is not an opption for us as we are urged to support devices which are actually in use.
Therefore, I'm building with the SDK version 126.96.36.199, but I also tried with 188.8.131.52 and got the same results.
The current REST API of our server application uses GET, POST and DELETE requests, so I had to use SocketConnection and build my own HTTP handling code to implement the DELETE method.
There are different instances of the server application (testing, staging, productive) with different hostnames, but for the standard use case from the end user point of view the app would stick with one host. Therefore I designed the code, which handles the application permissions related with network access, to just ask for the permission to access the currently configured host (-> getPermission(permission, domainname)).
Upto now, I used mostly just one host for the tests. I switched once the host when I had to use a host with a newer version of the server application software. Despite of carrier/network related issues I had never any problems to access the hosts.
But now, while testing the new code I suddenly ran into unexpected trouble.
At one point, I changed the hostname to use another server host and since then, I get a SecurityException whenever Connector.open() for a https-URL is called. I even get it after changing back to the previous hostname. The reason string is just "Permission denied".
I checked so far:
I find it rather suspicious, that I don't get the usual "application requests to establish a https connection" dialog when I use the https-URL.
I actually get the similar dialog when I change the code to use the SocketConnection for GET using a ssl-URL. The network access even works in this case, but my HTTP implementation is still too rudimentary to be useful for this case.
So, my question is: What may trigger this SecurityException? Which component actually does "deny the permission"?
And may be related: Is the permission to access a specific server via http/https or socket/ssl stored somewhere on the device in a way that it will even survive the de-installation of the corresponding app?
Am I looking in the wrong direction and there is something other going on here?
I would appreciate any help to get this case solved.
Thanks in advance,
Solved! Go to Solution.
04-21-2011 08:00 AM
I did some more elaboration on this subject.
I could reproduce this behaviour in the simulators for 9700 / 184.108.40.2060 T-MobileEU and 9800 / 220.127.116.114:
PLEASE! Is anybody out there, who can explain this to me and tell me how I can work around this issue???
Thanks in advance!
04-27-2011 03:19 PM
04-28-2011 07:37 AM - edited 04-28-2011 07:45 AM
I'm using mostly the Desktop Manager to deploy the application during testing. But some of my "Beta-Testers" get it via OTA.
But I found the real cause yesterday: due to some changes at another place, I got uppercase scheme names when creating the connection URLs.
Unfortunately, this "SecurityException: Permission denied" message doesn't point to the real issue, therefore I was searching at the wrong places.
Why not throwing an IllegalArgumentException instead? Accepting uppercase scheme names would be another option, as this is the recommended behaviour by the corresponding RFCs. (Ok, the RFC also states that a client should use lowercase scheme names, so this would direct the issue again at me. But then again - a correct description of the real cause would help very much...)
After all I found during this bug-hunt that HttpConnection actually does accept "DELETE" even with the SDKs for 4.5 and 4.6. At least enough that it works for my use cases. So my own SocketConnection based HTTP implementation wasn't so much necessary after all...
Thank you for giving some feedback after all!
P.S.: If somebody would just look into my other big show-stopper and could give me some feedback, I would be glad: