I have packaged a Sencha Touch 2 app with PhoneGap for Android. I can't get the ajax requests to work on my native application. When I handle the request through the browser on http://mydomain.com/mysenchaapp/android/assets/www/ it works fine, however, when I run my app through the emulator as a native app my request fails. I think it would be helpful if I could get fiddler to work on handling native apps' request as well, but I haven't been able to figure that out either. Any help is appreciated.
On a native application you can use cross-domain get requests without using JSONP. I got it to work. My problem accessing the servlet was another issue.
You can't use Ajax for Cross-Domain GET requests, you should use JSONP instead. Take a look at the documentation for Ext.data.JsonP.request(), You can however use Ajax to make a post if i'm not mistaken. This comes in handy when uploading something like a base64 string (which is too big for a GET request)
Related
I'm developing an Android application, it is like a browser, has a web-view and sends http(s) requests. For debugging purpose, I want to be able to see the requests sent and received by the application (in particular the headers), but I'm unable to do so.
What i tried
I mainly debug the app with Chrome on PC, and use the Network Inspector in Chrome. The problem is that my app uses the ShouldInterceptRequest to intercept the requests an then manually sends a request with cronet. Chrome, in this case, shows some "provisional headers" that are from the original request, an not the headers of the actual request i sent manually.
I tried to use Fiddler and HTTP Toolkit, but the server I'm communicating with, doesn't like the certificate they use, so they can monitor correctly, but, if active, i cannot reach the page i need to monitor.
I also tried the Android Studio network inspector, but seems it work only for HttpURLConnection and Okhttp(1)
Thanks for your time.
If you're using a WebView, set a custom WebViewClient and override shouldInterceptRequest. That will pass in a WebResourceRequest object that will include all headers.
I have a jHipster project with Jwt Authentication but I can't get it to work outside de webapp. I'm currently developping a Android application and the authentication process get harder than I expected.
Basically I'm sending the parameters of the LoginDTO, to UserJwtController#authorize ('/api/authenticate'). At first I was getting Unauthorized, both on Android or Postman (I'm using it to test the requests).
If I change the '/api' to permitAll, I'm getting 405, Request method 'POST' not supported.
EDIT
It was a wrong typo on Android :/
It works fine for me against /api/authenticate, so either you use wrong URL (e.g. /api/authorize) or your JSON payload is wrong. The only issue you could have is with CORS. You should consider testing with curl as it is easier than PostMan for reporting here what you really do and also the curl options are already built for you in JHipster swagger page.
I have started building simple Todo app in Ionic 1 and I discovered a problem with Origin header. (CORS related)
If i run
ionic serve
everything works fine in browser and i can make requests to my REST API on apache(tomcat). But when build my app for android or even in ionic viewer, all requests fail. Using a chrome debugger I managed to locate the problem.
Native app sends header (tested only on android)
Origin: file://
which causes my server to deny requests. Seems to me that it should send correct Origin header with host. Screenshot with more details is attached below.
What can I do about that?
Found related topic here: CORS, Cordova, AngularJs $http and file:// confusion
Already posted here, with no luck: https://forum.ionicframework.com/t/native-app-is-sending-header-origin-file-which-causes-problems/62388/1
EDIT: Problem occurs when post, if I run ionic starter (tabs) template with only $http.post('http://myapp.com/apiv1/device') added to controller.
Try adding the following to your allowed origin request: "file://* filesystem: "
I had the same problem with <iframes> in Ionic and I fix it adding:
Header set Content-Security-Policy "...; frame-ancestors 'self' file://* file://*/* filesystem: http://localhost:*;"
It seems that the problem comes from the server (specifically from Tomcat).
According to this bug:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60008
The default CORS filter provided by Tomcat (instances/shared/conf/web.xml) doesn't allow POST requests and returns 403.
The problem is solved from Tomcat version 8.0.37, so upgrading the server should solve your problem.
Regards.
I've came across this last week. I had to make POST request to JIRA api and I wasn't able to change server configuration.
Probably the easiest way is to make your own android plugin which sends POST request. If you send POST request from plugin, there is no Origin: file:// header and everything works fine. The plugin was like 2-3 hours of work.
I try to send POST requests (like forms) from my Android application to my Symfony backend but when I hit the 'Send' button for example, an Android FileNotFoundException ('http://192.168.1.84/1day-symfony/web/app_dev.php/api/request') is thrown. Maybe it is caused by the rewritten URL.
I do not know how to fix it...
Using Volley fixes the issue of the rewritten URLs.
I am re-implementing an existing worklight system. We have already have a hybrid version. We have decided to re-implement the Client side in pure native. The native client seems work fine.
However, the server seems to be quite unstable - sometimes we don't get a server response after invoking an adapter, sometimes we do get. I have checked the DDMS/Android console. And a Error/Exception was found. Any comments would be appreciated!
com.worklight.common.Logger$SendLogsRequestListener(4274): Logger$SendLogsRequestListener.onFailure in Logger.java:1726 :: Failed to POST data from file /data/data/${APP_NAME}/files/analytics.log.0.send due to: HTTP response code: 500
On a successful adapter call or WLClient connection to the server, the client will attempt to automatically send logs to the server. It looks like something bad is happening on the autosend for adapters. A temporary workaround would be to disable this auto sending behavior by calling
WL.Logger.setAutoSendLogs(false)
But you can only use this call if you do not wish for logs to be sent automatically. If you do wish to have this working properly, I'd suggest opening a PMR so that it can be determined if this is an error in your application or an actual defect.