I am considering using a well-known third-party framework in my iOS application, which uses the camera. Unfortunately, it makes entirely unnecessary HTTP requests to the third-party's API, allowing them to capture and track things like device ID, device type, OS version, and other information. The calls are completely unnecessary to the framework's purpose, and the framework works perfectly fine when the network connection is unavailable/disabled.
My question is whether or not it's possible at the application level (i.e. via code or configuration) to intercept and/or block any calls made within the app to a specific host, like api.thirdparty.com.
You might be able to create a custom NSURLProtocol and register it to handle HTTP/HTTPS. Then filter which URL's you let through. You could start with this open-source project to guide you - it demonstrates how to pass some requests through to the system HTTP/HTTPS handler, and handle others yourself.
https://github.com/rnapier/RNCachingURLProtocol
Related
We wanted to create a mobile app using flutter, I searched on how to connect odoo with external platforms or apps , I found there are two solutions:
The most common and standard one is to use the xmlrpc communication protocol, we did found some libraries with that name in flutter , but the problem with this is that it's a bit complicated for flutter devs that does not know how the Odoo architecture works.
The least common method is the endpoints or controllers method, basically you create endpoints in your controllers and just call it through http request from the mobile side, the problem with this method is that it's not standard and I did not see much people talk about it, I also heard that this method is for the web instead of mobile apps since the session_id of the identification is returned in the Cookies.
My question is the following, is the endpoint method good enough for mobile app? If no, are their any alternative of xmlrpc?
You can connect odoo with the flutter app using simple RESTful API requests, there are many packages in pub.dev which can help you
i am quite noobie about OpenStack components and role, and i am having trouble understanding how each component works and when they operate;
Suppose that i have a certain image in my openStack storage and a client uses it and complete some operation(like saving files); how is the interaction between the components to perform this operation?( i would like to know how and which conponents work from the creation of volumes to the changements saved;
Thank you very much.
Openstack follows Service Oriented Architecture. It uses WSGI and django framework. So, every component exposes few REST APIs.
You can find these APIs in api folder. For example (https://github.com/openstack/cinder/tree/master/cinder/api).
Internally, these API calls make call to manager. manager.py is the file which handles main logic. (https://github.com/openstack/cinder/blob/master/cinder/volume/manager.py).
It calls underlying driver classes and co-ordinate with other openstack services through their APIs.
I have a sample web API hosted in an OWIN process (self hosted, not in IIS). I get a JWT token in my controller and I want to be able to retreive it in another part of the application, a class that implements NserviceBus IMutateOutgoingTransportMessages. In my other web application POC (hosted in IIS), I used a simple session variable and it works just fine. But I'd like to know what would be the best way to do it in my new OWIN self hosted environment ? Static property in static class ?
This question is really broad and difficult to answer without detailed knowledge of your specific needs. Here's my interpretation of your issue:
You're already signing each request, perhaps storing the token in the browser sessionStorage (or even localStorage), but this does not suffice
You need to retrieve the token outside of or not in relation to any request cycle (if not, this is probably where you should be looking for answers)
Your application does not need to be stateless
Just one static property for one token in a static class would of course start breaking as soon as more than one request hits the application at the same time. Implementing a class that maintains a list of tokens may be a solution, although I can't tell what key you should use to identify each token. Interface details would vary depending on things like if you need to retrieve the token more than once.
Thread safety issues would apply to all handling and implementation of such a class. Using Immutable Collections and functional programming practices as an inspiration may help.
If lingering tokens poses a problem (and they probably would from a security perspective, if nothing else), you need to figure out how to make sure that tokens do not outstay their welcome, even if the cycle is for some reason not completed.
Seeing how you used Session as a solution in your POC, I'm assuming you want some similar behavior, and that one user should not be allowed to carry two tokens at the same time. You could store the tokens i a database, or even in the local file system, making maintenance and validity a separate issue all together.
There are implementations of cache-like functionality already available for OWIN self-hosted applications, and maybe one of those would serve as a shortcut to implementing everything yourself.
If this token business in fact is the only reason for introducing state in your application, then the best solution IMHO would be to rethink your architecture so that the application can remain stateless.
I'm facing a similar dilemma on a server i'm currently developing for a customer. My problem is that the server must make calls (and retain a live connection) with a legacy, multithreaded DLL, (aka the SDK).
I struggled to get this working on IIS with a regular Web API project. Failed badly since IIS recycles threads when it determines that a thread is going rogue... witch is what the SDK thread looks like in that perspective. Also, the SDK must be able to callback on the caller (client - single page app) and for this I'm using SignalR.
I then tried a multi-part system (single page + web api on IIS + WCF service for the SDK integration). But it is a real nightmare to manage because of the 2 way async communication that must occur between all apps. Again: failure.
So I reverted to a single self hosted OWIN + WebAPI service in a console app (for now). My problem is that some of the calls are lengthy and are processed in a worker thread. I managed to pass the SignalR client id in each ajax calls via headers. I can extract the id when in web api controller. But when the task goes async, I need to get the id (via an Unity injected service) from the class that manages the async task. This is where my problem is similar to yours. In IIS hosted apps, we have HttpContext. It is contextualized on each client calls, and follows any thread changes in the pipeline... But not in self hosted OWIN WCF apps...
I'm looking into Thread Local Storage, CallContext... and other means of keeping track of the original caller info during the lifecycle of the async call. I have read about OWIN pipeline, I can capture the info in a OWIN middleware... but how to safely keep that info for use in injected services? I'm still searching for an answer...
I was wondering if you have found a solution to this rather interesting problem ?
I prefer adding to your thread rather than start another parallel thread / SO question.
I have a web application (typical mvc webapp) that needs to call a REST API bundled in a different webapp (war file).
The first web app serves as a front to the separate REST API webapp for customers to register and view their stats, purchase plans etc. But part of the design of this webapp is that it must have example invocations to the other REST API webapp.
There are many rest clients out there, but what would be a reasonable approach to address the above?
I was thinking of using the Spring REST Template to call the REST API but from my mvc controller class in the first webapp. Is this a reasonable approach?
Once you deploy a webapp using your deployment tool of choice, you can simply call the REST URL. That's one of the great things about REST - it doesn't care about what sort of tool is calling it because it deals in a neutral medium (usually HTTP). Twitter's REST API (here) doesn't care what's calling it - in fact the beauty of it is that anyone can make an app that calls it.
So say you deployed a webapp locally to port 8080, you can just make a REST call to http://localhost:8080/firstapp/rest/foo.
If you're deployed to the World Wide Web, then just call the appropriate domain.
Yes, RestTemplate is a very convenient way for server to server REST calls. Though there are some tricks if you are going to serialize generics.
First there is TornadoWeb, it's async and non-blocking, and on the other side: there is Dojo. If I use tornado, how can I communicate with dojo?
And the other problem, if I use a WSGI solution like Flask, can I make a "notification" with them? Or dojo must have an "open connection" to speak with the server, which is not done using WSGI? mean; Apache or CherryPy will not work with Dojo?
And if WSGI can't speak with Dojo, what about using Atom or Feeds to program notifications under WSGI?
NB: the notification will be devided on two: notification about products for all users, and notification about specific users; it will use sessions...
And last question, what about WebSockets and HTML5? the server must be compatible to use this option with the browser?
I'm not sure why Dojo seems to be the problem in the communication.
Dojo provides you with AJAX wrappers which you can use for almost real-time notifications in a web app with little load by making an AJAX request each 1-5 seconds.
If the app will have a lot of users, frequent AJAX requests can cause too much overhead quickly. Fortunately, you don't have to use Dojo to communicate with the server. You could have a look at Socket.IO and, if you want to stick to Python on the server-side, gevent-socketio. It uses the best technology available in the web browser (WebSockets, Flash sockets, comet) to provide real-time communication.
There is also dojox.socket but I think it's less robust (and far less popular).
You should remember, however, that by using any kind of persistent connection (be it WebSockets, Socket.IO or dojox.socket) you need an asynchronous server able to maintain many simultaneous connections.
The solution you choose should depend on the web app itself and its user base.