We Keep Coding

How to securely create neo4j nodes via a webpage using java/html forms

I want to create a webpage where a user sets up a profile via a form; form data is sent to my server and creates requisite nodes in neo4j. I want to do this in a way that does as much as possible to prevent people arbitrarily sending commands to my server outside of the form, such as via chrome or any other injection method.
I expect that I will need to utilize the REST API to connect with neo4j via java. It also seems like I will need to use Jersey to allow the site to communicate with the neo4j REST API. I am new to securing data being transferred from the client to server and to validating data received by the server to ensure I am not sending commands to neo4j that shouldn't have been sent, and which could cause all sorts of damage to my members. I am also new to utilizing graph databases and neo4j in general.
Can someone give me a step by step example of how to basically accomplish this task? I am looking to find out what tools I need to install, and what types of commands I should include both on the client and on the server side to ensure that I am only passing correct data to neo4j when creating/deleting/modifying nodes and relationships.
Thanks for any help that anyone is willing to provide - getting past this hump will allow me to move so much more quickly with the rest of my development.

I guess the most easy way to prevent others from accessing your neo4j instance is using Neo4j authentication example. Just follow the docs on the start page. Additionally you might set up some IP address filtering using e.g. iptables on linux to restrict network access to your Java client machine.
With authentication extensions installed, you need to supply username/password with each request. The most easy way to communicate with Neo4j from a Java client these days is using the Neo4j JDBC driver.

Making a web service, which approach?

I have made a Java EE 6 application where a user can browse a set of questions, add new questions and so on. The user can optionally log in so that he/she gets "credit" for adding the question or reporting it as bad.
Now I want to make a iPhone application where the user can do pretty much the same. So the answer is web service I assume. I have not worked with web service before but I see there are at least to alternatives: SOAP and REST.
Which one should I choose? I want the user to be able to log in from the application as well a as browse the questions in the database...pretty much many of the actions you can do on the web site.
I don't know much about the security and overhead they introduce.
Also I want the user to be able to retrieve the list of questions thorugh the web server and have the option to save it, so he/she won't need to have internet unless he/she wants to update it. Can I achieve this with both web services?

REST has less overhead than SOAP (WSDL contract, XML messages, supporting frameworks) so when the client is a mobile device REST seems more suitable. You could use JAX-RS (Jersey) to easily create REST services on the server side. The client request consists of the url structure and/or parameters like http://yourserver/questions/view/342 (to view question 342) or http://yourserver/questions/search?q=REST+vs+SOAP (to search for questions about REST vs SOAP). The response can be anything you want, but XML or JSON is pretty common.
Choosing REST means you will be leaning heavily on the HTTP protocol. For security a common approach is to use HTTP Basic authentication in combination with https. Basic authentication means you add an 'Authentication:' header to your HTTP request containing a Base64 encoded username:password pair. Note that Base64 does not encrypt anything, it just obfuscates. To avoid eavesdropping you need to use at least https meaning requests are encrypted using the server's public key. These requests can only be decrypted with the server's private key. To use https you need to set up the server with a certificate. If you want to avoid warnings about the certificate being 'untrusted' it needs to be issued by a recognized SSL certificate provider. For testing you can just generate it yourself.
Finally you asked about saving a list of questions for offline usage. This is a concern of the app, not of the service. To do this you need to store the retrieved data on the device and access that data if the device goes offline. I am not an iPhone developer, but I can imagine you could use a flat file or some lightweight database to store the data. When the device is offline, the app component that retrieves data should switch from network access to local storage access. Also some app functionalities like adding a question might need to be disabled. If you don't disable these, you would need to temporarily store any data entered by the user and send it to the server when the device comes online again. This could be a bit tricky to get right so my advice would be to leave this for later.

You can take a look at this previous SO post for some guidance. I would recommend using REST, it seems to be less messy than SOAP and Java has support available for it as shown here.
Through the use of annotations, you can simply created a facade to which users will connect. In turn, this facade will call the relevant logic which I am presuming you already have.

Well on a simple search REST vs SOAP, you will eventually get to this
There are plenty of other articles and even in-depth research papers, so it's only a matter of - do you really want to get serious with your research VS not really
Good luck!

Short answer: Yes, you can achieve that with web services.
Web services are only a facade to your system - they can expose (or not) any behavior you want to. If you have security concerns, you'll have to approach them anyway in both methods.
Personally, I'd use a RESTful approach as its usually simpler to implement and use. From Wikipedia:
A RESTful web service (also called a RESTful web API) is a simple web
service implemented using HTTP and the principles of REST. It is a
collection of resources, with four defined aspects:
the base URI for the web service, such as http://example.com/resources/
the Internet media type of the data supported by the web service. This is often JSON, >XML or YAML but can be any other valid Internet media type.
the set of operations supported by the web service using HTTP methods (e.g., GET, >PUT, POST, or DELETE).
The API must be hypertext driven.[11]
So you'd have a URL, say http://mywebsite.com/users and perform HTTP actions (GET, PUT, etc) on them. A GET request on /users/17 could return user 17, for instance, while a POST request on it would update said user.
As for login, when your users "log in" you would call a GET method that sends username:password (probably encrypted) and returns a login token. Every time the user executes an action, you would send said token with the request as an additional parameter.

Usage of a Data Access Layer (DAL) in a SOA design

As we are in the beginning phases of rejuvenating our application in to SOA design I have some questions that I can not get a clear answer/picture on.
I have been doing a lot of reading, mostly around books from Thomas Erl and following that design pattern of understanding what Task Services, Entity Services and Utility Services are.
What I am stumbling on is the whole DAL concept of how that would look. So this is more of a verification of understanding or a clarification so as to help make the best approach for our platform.
So background. We currently have several web based e-commerce applications that have been pretty much been built in silos and are again pretty much a copy of each other. We have supporting applications such as Daemons and misc web services out there. Many of these applications are older then 5 years and are build on only technology (Model 1). All of our applications are centered around conducting auction sales. So during a sale event we will be taking bids from users, determine who is winning and display that information back. Each sale event has a set amount of time that they will be available to the users.
The company is moving towards a SOA solution as a lot of things we end up doing can be shared across not only our group but across other groups.
So what I understand on the DAL is that it in itself is a service which will sit on top of Data, in this case different Databases - MSSQL, ORACLE, MSSQL. Each of these databases have different schema's (Oracle) etc.
So the services (Task, Entity, Utility and Presentation Tier if needed) will make calls to the DAL to retrieve data. It is the responsibility of the DAL to know, from the contents of the message to determine what it needs to do in order to fulfill the request.
So for example, we have a Security Service candidate. This service needs to authenticate with LDAP and to authorize from the data that is stored for that given application.
The thought here is that a Utility service will be created to wrap up all the operations required to communicate with LDAP and that the Security Service will call upon the Utility Service and to the DAL to fetch the authorization data. The DAL then has the responsibility to go to the correct database/schema to retrieve the information. The information will be in XML format (standard SOA communication).
So, am I on the right track here? Have others done similar things or not? What other things do I need to consider (Currently getting the statistics on how many bids we take in an hour - on average).
Should each service have its own DAL - for example should the Security Service have the DAL as part of the service or should DAL be a shared service in which all services can use?

In your case, the approach to use for a full SOA based deployment would be to use an ESB, Identity provider and a data services solution.
To break it down, the DAL should be implemented using data services, in this way, this service will be a globally accessibly service in a language neutral way, and will support re-use and loose coupling. So all your data access logic can be implemented as web service operations in a data service.
So for the authentication and authorization management, in the SOA world, there's a standard called XACML, which is used for fine grained authorization management. So what you will need is an XACML server, who would authorize the user according to a specific criteria, where this should also have the ability to authenticate with LDAP.
Then your "Security Service" will be implemented in a service at the ESB, where that service will query the identity provider for authentication/authorization and according it's response, it will call the appropriate operations in the data service, with suitable parameters to fetch the data, and return it to the user.
The above scenarios can be implemented using WSO2 Data Services Server, WSO2 Identity Server and WSO2 ESB respectively, which are open source products, and can be freely used and found here.

i once worked with (developing) an soa project that used a "data service". it was some time ago, and i was only involved marginally, but my recollection was that it ended up being too complicated and slow.
in particular we had no real need for a data service - it would have made more sense to have placed the same abstractions in a library layer, which would have given better efficiency and no real loss of functionality (for our particular needs). this was exacerbated by the fact that the data tended to be requested in many small "chunks".
i guess it comes down to the trade-offs involved in the implementation. in our case, with a relatively closed system and a single underlying database technology, we could have easily exploited the support for distributed access that the database provided; instead we ended up duplicating this in a slower, more general, message bus, which added nothing except complexity. but i can easily imagine different cases where access to data is more "distant".

How you have to use SOA for your design is depends on the its requirements.
In generally you can write coarse grain services and expose them as web services. In your case you can write some services which calls the databases and produce the results. In this case authorization logic can also be written with the service logic.
The other approach is to use an ESB or BPEL engine to write the integration logic and expose the integrated service as a web service. In this case you can use some data services to expose data base data in xml format and integrate them. You can use services for different sachems and call the correct service with the request data. And the authorization logic can also be added to service integration logic.
Security aspects such as authentication, confidentiality, integrity is considered as non functional requirements and hence can be engaged to any service without writing an explicit security service.
Following articles describes such sample possible integration of services as mentioned in the second approach.
http://wso2.org/library/articles/2011/05/integrate-business-rules-bpel
http://wso2.org/library/articles/2011/06/securing-web-service-integration

Web Service vs TCP/IP Sockets (Java) + SQL Connections

We are currently are at a stage in our product lifecycle where we are thinking about moving to Web Services. Our system is written in Java which consists of a number of client and server applications which talk to one another over TCP Sockets and also has in-line SQL to perform data retrieval and updates (yuk! I know) which uses our own SQL Connection class which then uses the java.sql.Connection to connect to a SQL Server database using the Microsoft JDBC driver.
The applications bind to one another using TCP sockets. They request data from and push data to one another. Which works perfectly fine.
Thought
So we are looking at converting all data access and TCP communication to a web service.
The web service would be designed to run on a companies secure internet site. The idea would be that users could connect their clients to the web service from home - when they are not on the company network - or at work, when they are.
The client applications would send/recieve the messages to/from the server side applications using the web service.
The client applications would retrieve and update data in the database using the web service.
Question
I would just like to know what peoples experience is of doing anything with 2 way communication (request and push) over a web service (if possible) and what the thoughts are about doing this.
Converting the data access to a web service seems straight forward enough - I can forsee some issues with performance where large data sets are retrieved in some parts of the system.
I am looking through various reading materials on the matter as it is a while since I have touched web services (using C# and ASP.NET). Currently reading "Building Web Services with Java™: Making Sense of XML, SOAP, WSDL, and UDDI". I must admit I thought web services were always stateless but have just read that they are not!
Thanks,
Andez

It helps to think of WebServices as being the same as any other web application on the transport layer. It uses HTTP/HTTPS protocols in the same way, it's just that instead of sending HTML, it sends XML according to a predefined format (SOAP). As such:
It's Request/response oriented
Can be stateful in the same way as a web-page can be stateful, using sessions (assuming you have a web-service client that supports maintaining session cookies across requests)
All requests eventually boil down to good old-fashioned servlet endpoints in the server
Keeping these limitations and features in mind, think about your requirements and how they map against each other. If you need true two-way communication (push), then web services are not ideal. They are client/server, request/response oriented. The achieve push, you would have to poll from the client. A possible alternative could be to let both the "server" and the "client" act as web service "servers". That would mean bundling some light-weight servlet engine with the client (like jetty) so the "server" could make web service calls TO the "client". Another way is to look at two-way RMI/IOOP.
Yet another way would be to keep the communication layer as you have it today. There is no inherent gain in refactoring to Web Services just for the sake of using web services. If they don't add any benefit, it's just waste. As you already mentioned yourself, Web Service comes with a load of additional overhead (verbose protocol, servlet engine etc), so it really needs to balance the extra cost and development time with a clear benefit. As the saying goes "if it's not broken, don't fix it". As you say the current solution "works perfectly fine", I would probably not change it. That's just me though.

How best can I isolate my application from an unreliable database?

I have a Java SOAP data service which sits on top of a Sybase database which, for reasons out of my control, has unreliable performance. The database is part of a vendor package which has been modified by an internal team and most of the issues are caused by slow response times at certain times of the day.
The SOAP service provides data to a calculation grid and when I request data, I need the response time to be both fast and consistent. The service provides basic CRUD functionality, but the ratio of reads to writes is approximately 100:1.
What is the best strategy to isolate myself from the database's unreliable performance and ensure that the SOAP service is fast and reliable?

I have seen this issue a few times, normally with a vendor database.
If this is on Windows, you could create a Windows service as an intermediary between the SOAP service and the database. Then put a message queue (either MSMQ or a JMS implementation such as MQ Series) between the SOAP service and Windows service for asynchronous communications. In this way the database performance issues will no longer affect the SOAP service. This solution does, however, come at the cost of increased complexity.
Note that a .NET web service can be called by, and respond asynchronously to, its clients. I'm not sure if that's possible with a Java SOAP service.
If this is on some flavour of Unix, I assume it has similar functionality to a Windows service - maybe a daemon.

Why not use a thread? That way, the application could gently wait even if the database is slow.

RoadWarrior's response is right on. Requests to do any operation get put in a queue. The user comes in once to make the request, and once to pick up the request. This is in fact what is happening on sites like Expedia where it is talking to an unreliable service (the backend). The user's browser is pinging the server until the red light turns green.

How about caching the responses from the web service (either on the client invoking the WS request, or by setting up a proxy web service in between)?

You could cache the results from the DB if the DB Is not too big.

Get the other internal team to tune that database, so everyone using the app benefits. I do love me some indexes!