02-18-2013 01:49 PM
I've developed a playbook app that allows you to control a wdtv media player on your local network via wifi. It does this via an Ajax post to a user configured ip address. The configuration.xml file has uri="*" in the access attribute.
The playbook app submits posts as expected.
"If the domain requires access to APIs or accesses data through XMLHttpRequest, you must explicitly specify the domain in the uri."
What are my options given that the app only knows the uri at runtime?
02-18-2013 05:23 PM
That's a good point actually
If you're on a private network like 192.168.x.x you shouldn't need to whitelist as there's no danger to the world at large
I'd stick it in as a bug report
I can't see an obvious way around it without a lot of messing around like forcing static IPs etc or sending it out to a server then getting it back via a PC and relaying the message
Not familiar with the WD kit but you could also possibly use a dynamic DNS on them
No simple solution comes to mind that makes it 'just work'
02-18-2013 06:21 PM
I don't suggest this option in a produciton environment.. For testing you can add the following to your config.xml:
<feature id="blackberry.app"> <param name="websecurity" value="disable" /> </feature>
This will disable web security for your application, allowing you to access any URI. http://developer.blackberry.com/html5/documentatio
02-19-2013 12:30 PM
There is nothing stopping you from using this in a Production app, but it is recommended only as a last resort,
02-19-2013 12:32 PM
I missed the disable web security feature (handy to have)
In your case I think it's valid to use it for now - just validate the IP is 192.168.x.x.
If you do a search for Wifi on any wifi-enabled device just about all of them will be using 192.168.0.1 as their address unless the user changes the router settings
The issue is that on install the user will get a big pop-up saying you want to disable web security before you can say why (which makes it sound like something bad)
As I said - I really consider this being a bug
Then again it could potentially be mis-used in a public area - e.g. at a HotSpot point
Pinched from Wiki - The private network address space
|RFC1918 name||IP address range||number of addresses||classful description||largest CIDR block (subnet mask)||host id size||mask bits|
|24-bit block||10.0.0.0 - 10.255.255.255||16,777,216||single class A network||10.0.0.0/8 (255.0.0.0)||24 bits||8 bits|
|20-bit block||172.16.0.0 - 172.31.255.255||1,048,576||16 contiguous class B network||172.16.0.0/12 (255.240.0.0)||20 bits||12 bits|
|16-bit block||192.168.0.0 - 192.168.255.255||65,536||256 contiguous class C network||192.168.0.0/16 (255.255.0.0)||16 bits||