Is there any mail sending api/service for android applications apart from Java mail API?
Right now I am using javamail API and after testing it I thought its working fine but actually its getting blocked when used from some other network despite of allowing access for less secured apps in Gmail setting of that particular account.
I don't mind even if some paid service is available for few bucks.
This is not required for bulk mails. Required for functionality like feedback of app.(I don't want to use firebase and all because there is no mechanism for login in my app)
Thanks
It's a bad idea to embed mail server credentials in your app, it's too easy to abuse them. Better to create a web service to accept the feedback and then use JavaMail on the server to send it, if you still even need email. You can limit the functionality of the web service to make it harder to abuse.
Related
I'm building a mashup app for Android Wear, using speech recognition so I can post to Fitbit's API. Single-purpose and pretty simple. I generated the OAuth 1.0 credentials with the excellent Temboo library and granted access in a desktop browser, then naively hard-coded those keys and tokens into my app and let Temboo take care of the HTTP requests and API calls to Fitbit.
I've gotten errors from Fitbit stating that my requests are being refused by Temboo's server because of invalid OAuth signature (Fitbit uses OAuth 1.0). I've come to the realization that I probably need to have the user grant access on the wearable app itself. I'll need to launch the mobile browser and pass it the authorization URL from Temboo in a WebView, then have the user grant access, and then pass this approved data back to the watch.
Is there a pattern for doing this in order to allow access to third-party web service APIs already? I've not seen documentation on it so far. Does anyone have a tip on how the authorization process would flow for a wearable watch app?
Thanks much!
There is no web browser or direct internet connection on Android Wear devices - all web connections must be done on the phone part of your app and then forwarded to your Wearable app via the various Data Layer API methods - using messages is an easy way to send information in a lightweight, time sensitive manner.
Therefore your phone app should do all of the OAuth dance as part of an initial setup.
I have a public REST API that I want to protect. I've read about HTTP basic authentication, OAuth, APIs Key ... but as far as I know, this methods require registration (username and password). I want that the users (Android apps) of my service can use it without registration and login.
So, ideally, I want that only Android apps can use the service and I would like to control the usage of the service. I've thought about get something unique about Android devices but I think it is easily falsificable.
The reason for no registration is that the service is very simple (check out the bus arrivals, and participate sending some time arrivals) and I think is overkill that users have to provide a username/password for such a simple service.
How I can achieve this?
I want that only Android apps can use the service... How I can achieve this?
You can't.
You can try to casually reduce the number of things other than Android apps that can use your service (e.g., have your app use a custom user agent header in the HTTP requests, and use SSL). However, people who are determined to get past that will be able to do so, by reverse-engineering your app, or sniffing on the HTTP traffic.
I have two android devices that runs a gcm client app. I get the Reg IDs of both the devices. I also have a server API key. Now the thing is, Using a simple php code using cUrl or Zend framework, I'm able to send message from a web server to one of my droids (Of course I can broadcast too). But, with this in hand, is there any way to send a string from one device to another?
Quoting myself from my book:
You might be tempted to use GCM for peer-to-peer messaging, without a server of
your own. In effect, each Android app is its own server, using the same JAR you
might use in a Web app inside your Android app to send messages to some other
party. For example, you could implement a chat system without having a dedicated
chat server.
The danger here is that this would require your API key to be embedded within
your Android application. Anyone with that API key is perfectly capable of forging
messages from you. The IP address restrictions you could place on that API key are
unlikely to help, since your legitimate uses might come from any IP address, not
just some single server. Since finding magic strings in APK files is not that difficult
for those with the inclination, putting your API key in your APK file is a dangerous
move.
Hence, you will want some server of your own as a middleman.
One thing you could do is to make a POST request to your web server with the message and the registration ID of the other Android device, but that would be a little cumbersome as you'd have to figure out a way to retrieve the registration IDs of the other Android devices from your web server.
I would recommend looking into XMPP as this protocol has been built from the ground up to be an extensive messaging protocol. I'm pretty sure you'll find good XMPP server frameworks to implement your functionality.
I'm planning to develop an Android application with an app-engine backend.
However I would like to refrain from using authentication (either with Google accounts or Open ID). Since the data will be sent only from my app and not any other client, and will be over SSL connection, I consider the data safe and trusted.
So my question is two-fold:
Is there any security issue I'm missing here ?
All the examples I found use some sort of authentication. Is it at all possible to use the android appengine infrastructure (RequestFactory, etc) without authenitcation ?
An app engine application is just a regular web application deployed on app engine. If you need to authenticate your users, do so. If you don't need to, then don't.
You're missing something, though: once a web app is deployed on app engine, it's accessible from anywhere on the web, and so anyone (and not just your app) could send requests to this application, whether you use SSL or not. SSL will just make the communication encrypted, and ensure the client that they're talking to your web app, and not to a rogue web app maskerading as yours.
What is the best solution to secure a REST service provider (assume a java servlet running on google appengine) by allowing requests only from iOS or Android device from a specific app?
Assume I have a servlet running on google appengine that does some processing and responds to a GET request with some JSON data. And I want to restrict this access to my app that runs on Android and iOS.
My current solutions are:
Use if(tokenValue ==
request.getHeader(tokenKey)) on the
appengine servlet. And
response.addHeader(tokenKey,
tokenValue) on the mobile apps'
code. So basically only my app would
know the token key.
Use HTTP(s) for the above solution, appengine supports this
Use oAuth - but I need to have the user sign-on to some oAuth provider from the app, which complicates the app
Suggest other useful approaches to tackle this problem. Assume this servlet only serves GET requests and maybe use Restlet or Jackson
Only 3 would be an appropriate solution if security is important to you. This is because anyone using the application can intercept the traffic and just replay the values against your web service. SSL offers some protection but a good attacker can work out how to capture data if they control the device. With OAuth the damage done by an attacker is limited to a single user (as long as they are not an app admin).
How about using a client SSL certificate? I haven't tried this, but I'm considering it. Here's a page that describes the approach, with some sample code:
http://blog.crazybob.org/2010/02/android-trusting-ssl-certificates.html