I got this email from Amazon saying that some of my app's use SSL to access S3 buckets. After I contacted their support, they gave me a list of clients, which points to my iOS app running on iOS7/8. I use AWS iOS SDK version 1.7.1.
The first thought came to my mind was obviously to update the SDK to the latest. That cost quite some effort due to the major difference between 1.x and 2.x of the SDK. After that, I tested with simulator pointing to their testing end point with SSL disabled. It worked, great!
But tonight I did some reading on AWS forum, in one thread, AWS claimed that all versions of their iOS SDK support TLS... things simply do not add up.
Anybody can think of a reasonable explanation to this? If it is not the SDK, and I obviously never altered the SDK in anyway, what caused SSL accesses to show up on their report?
If you have not modified the SDK or not implemented the NSURLConnection's authentication related delegates to manipulate the security model, a proxy can be a potential cause.
Some of the mobile devices may be behind a proxy, and it prevents the proper TLS negotiation. You may need to identify which mobile devices are using SSL and see if there are any common network components between them and the AWS service.
Related
I have written a real-time multiplayer game and currently writing its server in NodeJS. I want my game to have login, level up etc, so I need to have a database. This is the first time I am deploying something and I am mostly self taught, so please correct me if I am mixing things up. Since this is my first trial, I do not want to make much commitment right away so I am looking for free options only. And since this should be a real-time game, I need a relatively fast server response. That is why I am looking for the easiest database and server provider that would do and I am aware that with those restrictions I have limited choices and functionality.
As far as I have read online, Heroku seems to be my simplest option for a server (that is why I started writing in NodeJS). However it seems like there is no free database service since all options on https://devcenter.heroku.com/articles/heroku-postgres-plans has monthly fee. I did not want to use Google App Engine since I am new (it certainly is not mentioned as beginner friendly).
So I have found AWS following Free Cloud Database Service for home development post, it seems like I could use Amazon Web Services as a server and database. However most posts I have encountered suggests Google App Engine or Heroku with little mention of AWS. Is this because I am mixing concepts up, or does AWS have drawbacks that I am not aware of? Do you think it is a good idea to use AWS for both as server and database, is it possible to use Heroku as server while using AWS as database or do you have any other suggestion?
Note: Sorry for the question bombardment but those are all related and I am sort of lost in this topic so I had to ask...
Use AWS EC2 for the server and RDS for the database. The reason why people use heroku is that it deploys to a custom url very quickly (it's easy to set up). Setting up AWS requires some knowledge of how servers work, but it's not that complicated (and it's free for small apps). Best of luck!
I am completely new to elasticsearch but I like it very much. The only thing I can't find and can't get done is to secure elasticsearch for production systems. I read a lot about using nginx as a proxy in front of elasticsearch but I never used nginx and never worked with proxies.
Is this the typical way to secure elasticsearch in production systems?
If so, are there any tutorials or nice reads that could help me to implement this feature. I really would like to use elasticsearch in our production system instead of solr and tomcat.
There's an article about securing Elasticsearch which covers quite a few points to be aware of here: http://www.found.no/foundation/elasticsearch-security/ (Full disclosure: I wrote it and work for Found)
There's also some things here you should know: http://www.found.no/foundation/elasticsearch-in-production/
To summarize the summary:
At the moment, Elasticsearch does not consider security to be its job. Elasticsearch has no concept of a user. Essentially, anyone that can send arbitrary requests to your cluster is a “super user”.
Disable dynamic scripts. They are dangerous.
Understand the sometimes tricky configuration is required to limit access controls to indexes.
Consider the performance implications of multiple tenants, a weakness or a bad query in one can bring down an entire cluster!
Proxying ES traffic through nginx with, say, basic auth enabled is one way of handling this (but use HTTPS to protect the credentials). Even without basic auth in your proxy rules, you might, for instance, restrict access to various endpoints to specific users or from specific IP addresses.
What we do in one of our environments is to use Docker. Docker containers are only accessible to the world AND/OR other Docker containers if you explicitly define them as such. By default, they are blind.
In our docker-compose setup, we have the following containers defined:
nginx - Handles all web requests, serves up static files and proxies API queries to a container named 'middleware'
middleware - A Java server that handles and authenticates all API requests. It interacts with the following three containers, each of which is exposed only to middleware:
redis
mongodb
elasticsearch
The net effect of this arrangement is the access to elasticsearch can only be through the middleware piece, which ensures authentication, roles and permissions are correctly handled before any queries are sent through.
A full docker environment is more work to setup than a simple nginx proxy, but the end result is something that is more flexible, scalable and secure.
Here's a very important addition to the info presented in answers above. I would have added it as a comment, but don't yet have the reputation to do so.
While this thread is old(ish), people like me still end up here via Google.
Main point: this link is referenced in Alex Brasetvik's post:
https://www.elastic.co/blog/found-elasticsearch-security
He has since updated it with this passage:
Update April 7, 2015: Elastic has released Shield, a product which provides comprehensive security for Elasticsearch, including encrypted communications, role-based access control, AD/LDAP integration and Auditing. The following article was authored before Shield was available.
You can find a wealth of information about Shield here: here
A very key point to note is this requires version 1.5 or newer.
Ya I also have the same question but I found one plugin which is provide by elasticsearch team i.e shield it is limited version for production you need to buy a license and please find attached link for your perusal.
https://www.elastic.co/guide/en/shield/current/index.html
I've went through several examples (shown below) based on the hopes that I could get WCF to work on the 4.0 framework in Mono.
Installing a Mono-Server for WCF
Indigo Infocard
However, the link on http://www.mono-project.com/WCF didn't seem to contain a "guide" so to speak as to "here's how to setup wcf on linux with mono". On a side note. I think I've checked the first two pages of google for most wcf/mono keyword combinations to no avail.
Is it possible to easily get a WCF service up and going on linux? I presume there may be some configuration on the apache2 side? (I'm running a lamp server with Ubuntu 11.10).
I took the stock 4.0 WCF Service Library and tested deploying it to my server and accessing the *.svc to see if I got the wsdl, however, I did get a status code of 500.
As far as alternatives. I'm thinking that http://www.servicestack.net/ is probably the best?
So there are a couple of questions:
Can you get WCF to work on Linux easily? If so, how? (Windows was easily done)
SOA Alternatives. Should I look at asmx (wcf did replace this) or go with Service Stack.
My goal (in a basic sense) is to pass data to a service and have it compute work. Nothing is returned.
servicestack.net itself (and all the live examples) runs on an Ubuntu 12.04 on a Hetzner vServer. All our live demos run on Nginx/MonoFastCgi.
Here is how to run a ServiceStack self-hosted service inside a Linux daemon which also includes configuration of hosting it behind an Apache or Nginx reverse proxy. This post was written by a team who moved to ServiceStack to fix their memory and performance issues with MVC on Mono.
I generally avoid trying to run any heavy Microsoft web frameworks on Mono unless the Mono team has expressed supported configuration. For WCF they've stated only the "Silverlight subset" of WCF is supported.
Microsoft themselves don't support or test on Linux so you will generally have a better experience with others that do.
I've also answered what I believe are the main differences between ServiceStack, WebApi and WCF in an earlier question here.
Ubuntu 11.10 has a very old version of Mono.
If you use Ubuntu 12.04, as it includes a newer version, it may just work.
We are currently using Amazon's SimpleDB for a web service. The data is very simple and doesn't require anything like SQL. Its basically a 'property bag'.
We are due to demo our project somewhere where we will not definitely have Internet access and thus may not be able to access SimpleDB. This has only just become apparent and I have been asked to look for service that we can run on a local server that would provide us with a like-for-like (i.e. calls to SimpleDB would work the same on this service) so that we could just direct our code to this rather than the real AWS SimpleDB service without any code change.
Is anyone else doing something similar? What are you using?
We also use Azure, so rather than change our app to work with one service online and another offline, we may change it to only use Azure as this can be run offline and still work.
Windows Azure table storage does not really work offline per se. The storage emulator can be run without an internent connection. However, it is an emulator. So, it does not have 100% fidelity with the cloud service and it is not tuned for any type of performance comparison. You could use this for demos, but I would not suggest using the emulator for any type of 'real' work. Crazy thing about cloud services... they don't work very well offline. ;)
You could maybe use a local version of redis - http://redis.io/ - but this definitely would require some recoding - not like-for-like calls
If the application was written to be testable (meaning you are using something like the repository pattern) you could possibly stub the calls and point to either a very lite Db or a file.
As a reference for anyone who ends up here looking for the same...
We eventually used mdb/node.js which uses the same api calls as SimpleDB. All we had to do was point our app at a new Service Endpoint URL (our MDB Node.js server - which was handily a VMware application that we ran in VMware Player).
This worked perfectly, but thankfully we never actually needed it as we could access the real SimpleDB.
https://github.com/robtweed/node-mdb
http://gradvs1.mgateway.com/main/index.html?path=mdb
Neil
I'm hoping someone can validate or correct my conclusions here.
I'm looking into writing a small side project. I want to create a desktop application for taking notes that will synchronise to a web-server so that multiple installations can be kept in step and data shared and also so that it can be accessed via a browser if necessary.
I've kind of been half-listening to the noises about CouchDB and I've heard mention of "offline functionality", of desktop-couchdb and of moves to utilise its ability to handle intermittent communications to enable distributed applications in the mobile market. This all led me to believe that it might be an interesting option to look at for providing my data storage and also handling my synchronisation needs, but after spending some time looking around for info on how to get started my conclusion is that I've got completely the wrong end of the stick and the reality is that:
There's no way of packaging up a CouchDB instance, distributing it as part of a desktop application and running it in the context of that application to provide local storage and synchronisation to a central database.
Am I correct here? If so is there any technology out there that does this sort of thing or am I left just rolling my own local storage and maybe still using CouchDB on the server?
Update (2012/05): check out the new TouchDB projects from Couchbase if you are targeting Mac OS X and/or iOS or Android. These actually use SQLite under the hood (at least for now) but can replicate to/from a "real" CouchDB server. Another clientside alternative that is finally starting to mature is PouchDB, which runs in IndexedDB capable browser engines. Using these or using them to inspire similar port to another desktop platform is now becoming a better-trod path.
Original answer:
There's no way of packaging up a
CouchDB instance, distributing it as
part of a desktop application and
running it in the context of that
application to provide local storage
and synchronisation to a central
database.
At this point in time, your statement is practically correct although it is possible to include CouchDB in an app — for an example see CouchDBX.app which is a thin wrapper around a prefixed bundle of CouchDB and all its dependencies.
The easiest way to build a CouchDB app is to assume that the user will already have a CouchDB server running. This is easier than it sounds, especially with Couchone's hosting or a prebuilt app like CouchDBX on OS X or DesktopCouch on Ubuntu. This latter is especially interesting, because if I understand correctly it is included by default with Ubuntu these days, and automatically spins up a CouchDB server per-user when you query its port via D-Bus. Something similar could (and should) be done on OS X using launchd and Bonjour.
So as you write, you either would design your app to store data in a local format and optionally sync with a CouchDB service you provide or you'd have to build and bundle all of Erlang, SpiderMonkey and CouchDB together with your app along with some scripts to make sure it was running when needed. This is possible but obviously neither of these are ideal, and believe me you're not the only one wanting a simpler solution for desktop-oriented apps!