Does Sencha Touch offer any security model?
How compatible it is with custom or other predefined security models like Spring?
Sencha Touch is agnostic: that is, it neither provides a security model of its own nor limits you to the use of a particular server-side model. If Spring is your thing, and if its security model is accessible by a REST-like API (which is the case), then it's perfectly feasible.
That said, there are at least two other dimensions to consider: one is transport layer security, the other is encrypted local storage. Sencha has nothing to do with these, either, but they're also important to your app. TLS is a deployment concern; encrypted local storage is more or less a DIY project, although there are some libraries out there to assist, javascrypt and Stanford Javascript Crypto Library among them.
Related
I am attending a training course where they presented the following graphic as the Anatomy of a Typical Java Web Application. Is it too sweeping of a statement, or is it largely accurate?
Here it goes:
(Disclaimer: My experience is drawn mostly from non-Java platforms, though I have some limited experience with Java - but mostly I'm not a fan)
It's accurate - but only for applications using that architecture - which makes this statement somewhat of a tautology.
I'll break it down:
Service Consumer Perspective
A "service consumer" is also more commonly known as a client.
"Service interface files" are not needed to build a client.
I assume by "interface files" it's referring to things like a SOAP WSDL document or Swagger file for REST services. These files are not generally used by clients at runtime but are used to automatically create client class-libraries at design-time - but you can always build a client without any code-generation or reuse of Java interface types.
If it is referring to the reuse of the server/application's Java interface types then the diagram is only accurate for client+server applications that are all-Java and are both designed/created at the same time (which is an old practice from the days of SOAP). Thesedays everything made in the past 5-10 years is RESTful and returns JSON data, but Java interface types are insufficient to model unstructured data like JSON (given you can't model discriminated-unions without concrete classes... in exception handlers, egods, and discriminated-unions are an important tool to model JSON in OOP languages).
Service Provider Perspective
I disagree with the use of the term "Front controller" being used to refer to what is commonly known as a back-end web-service controller, Servlet, or Spring Controller as "front-end" generally refers to the user-facing UI/UX, such as the rendered HTML+JS, an SPA front-end, or rich-client/fat-client (granted, this would be the "service consumer").
You don't need "service metadata" to have a web-application or a web-service - though if you're shipping a web-service designed to be consumed by disparate or non-first-party clients then its a good idea to make a WSDL, Swagger, or whatever metadata or service-description system your platform uses so that your consumers can generate their own strongly-typed clients.
"Service implementer perspective"
So this is my biggest objection: this diagram assumes that the web-service will be 3-tier and the controller/Servlet code is only a thin layer in front of "application" types located elsewhere in the system. While this is common in large-scale and complicated applications where you'll have host-agnostic application code that is designed to be able to run in, for example, an integration-test or unit-test host - or as a desktop application, in my experience I estimate most projects lump all application logic inside the host-specific (i.e. Spring, Servlets, etc) code because it simplifies things greatly (and because those hosts often support testability anyway - and the idea of reusing application code libraries as-is for desktop or mobile applications just doesn't work out well in reality given the massive differences between the disconnected and stateless model of web-service requests compared to the needs of stateful in-process client applications).
In summary: it's not wrong, but I don't believe it accurately describes the majority of (Java) web-applications I've personally dealt with... but this is my subjective opinion and I know that Java web-application and web-service frameworks like Spring and Java EE are designed for and encourage 3-tier architecture, I wouldn't describe them doing-so as an example of the pit-of-success - I feel this is partly due to shortcomings in the Java language design (and the fact these frameworks were designed over 20 years ago before things like generics were added to the language).
I am researching to start a new project based on Liferay.
It relies on a system that will require its own data model and a certain agility and flexibility in data management as well as its visualization.
These are my options:
Using Liferay Expando fields and define their own data models. I must do all the view layer.
Using Liferay ECMS adding patches creating structures and hooks that allow me to define data models Master - Detail. It makes much easier viewing issue (velocity templates), but perhaps is the most "dirty" way.
Generating data layer and access to services with Hibernate and Spring. (using Service Factory, for example).
Liferay Service Builder would be similar to the option of creating the platform with Hibernate and Spring.
CRUD generation systems as OpenXava or your XMLPortletFactory
And now my question, what is your advice? What advantages or disadvantages do you think would provide one or another option?
Thanks in advance.
I can't speak for the other CRUD generation systems but I can tell you about the Liferay approaches.
I would take a hybrid approach.
First, I would create the required data models as best as I can with the current requirements in Liferay Service Builder and maintain them there as much as possible. This would require that you rebuild and redeploy your plugin every time you changed the data model but would greatly enhance performance compared to all the other Liferay approaches you've mentioned. Service Builder in that regard is much more rigid and cannot be changed via GUI.
However, in the event for some reason you cannot use Service Builder to redefine your data models and you need certain aspects of it the be changed via GUI, you can also use Expandos to extend the models you've created with Service Builder. So, it is the best of both worlds.
On the other option, using the ECMS would be a specialized case and I would only take this approach if there is a particular requirement it satisfies (like integration with the ECMS).
With that said, Liferay provides you many different ways to create your application. It ultimately depends on how you're going to use your application.
Security always tends to take the last place in a new project. Or you use a framework like Spring where security is already build-in and can be switched on easily.
I try to find an open security framework that can be plugged-in to both Swing and Web applications (and JavaFX?), maybe easy to digest. I looked at plain JAAS, JGuard and JSecurity but its just too complicated to get started.
Any recommendations or experience to share ?
I am working with NB, Glassfish and MySQL.
Thanks
Sven
I have just taken a view of this http://shiro.apache.org/
Apache Shiro is a powerful and
easy-to-use Java security framework
that performs authentication,
authorization, cryptography, and
session management. With Shiro’s
easy-to-understand API, you can
quickly and easily secure any
application – from the smallest mobile
applications to the largest web and
enterprise applications.
I would strongly recommend learning JAAS. It really isn't that difficult to pick up, and there are some useful tutorials and a reference guide on the Sun web site.
In my experience, JAAS is pretty widely used, so it's definitely something you'll be able to reuse once you're learnt it. It also happens to be one of the building blocks for the Glassfish authentication mechanism!
I have done a similar research in JAAS for web application and has ran into a "mind roadblock" until I finally realize JAAS is a framework addressing security at a different "layer" then traditional web applications in the Java World. It is build to tackle security issues in J2SE not J2EE.
JAAS is a security framework build for securing things at a much lower level then web-application. Some example of these things are code and resources available at the JVM level, hence all these ability to set policy files in the JVM level.
However, since J2EE is build on top of J2SE, a few modules from JAAS was reuse in J2EE security such as the LoginModules and Callbacks.
On the other hand, Acegi, aka Spring Security, tackles a much higher "layer" in the securing web-application problem. It is build on top of J2EE security hence J2SE hence JAAS. Unless you are looking to secure resources in the J2SE level (classes, System resources), I don't see any real use of JAAS other than the using the common class and interfaces. Just focus on using Acegi or plain old J2EE security which solves a lot of common web application security problems.
At the end of the day, it is important to learn which "layer" of the J2EE-J2SE security issue you are tackling and choose the write tool(s) for the problem.
I would recommend you take a look at OACC (http://oaccframework.org). OACC was designed for solving the problem of application security. Unlike most frameworks OACC is able to store/manage the authorization relationships in your application. OACC's authorization model is more powerful that Shiro or Spring Security.
There is alternative from JBoss. A new version for PicketBox. More information here:
https://docs.jboss.org/author/display/SECURITY/Java+Application+Security
apache shiro miserably fails when you stress a web application under JBoss (say 2 million requests of a simple GET with a concurrency of 50 threads).
was very dissapointing to find out this.
it happens when you use filters.
You can read http://code4reference.com/2013/08/guest-posttop-java-security-frameworks-for-developing-defensive-java-applications/
It gives 1000mile view from various Java Security framework, such as JAAS, Shiro or Spring Security. All are depended on your requirements and technology stacks that you choose
I have a mixed UI (Win App, WPF App, and soon an ASP.NET MVC App) setup, so far I'm using Client Application Services for security. I know how to programmatically get a user authenticated and doing so is working beautifully. However...
I want to implement some cross cutting that basically checks to see if the user is authenticated all the time. Since everything will be accessing web services I want to enable this as a standard execution for pretty much everything the UI does. So far I'm thinking the PIAB - Policy Injection Application Block - will serve that function. What I'm wondering is two things;
1 Will the PIAB cover that needed functionality? Verifying authentication at every practical step if used against the UI?
...and...
2 Are there alternatives out there besides the PIAB? I'm curious to do a comparison of aspect oriented policy injection frameworks.
I'm not really familiar with Client Application Services but from my experience, most AOP frameworks wrap interfaces in order to implement the cross-cutting functionality. If CAS uses interfaces, you could probably just wrap them with what ever functionality you require.
Alternative AOP frameworks:
Spring.NET
Castle Dynamic Proxy
Spring.NET and Dynamic proxy seem to work in much the same way and have much the same performance in my Hello World type tests (about half-way between direct calls and invoking through reflection). PIAB is significantly slower than both these frameworks and I found bit more verbose. It does have the ability to be configurable via xml and I'm not sure if that's a good thing or not. Not sure if the other frameworks provide that. It does of course have the MS stamp of approval though :P.
Recently, I've become quite involved experimenting with lightweight grid frameworks (Hazelcast, Gigaspaces, Infinispan).
However, I've been somewhat surprised than none of the free frameworks I tried has any ACL or role based security features built in (Gigaspaces does have some measures).
What approaches are generally used to compensate for this? Am I supposed to only use the grid to share data between trusted server-side applications and use the traditional Java EE stack (i.e. a conventional DAO-layer) to access data from client or non-trusted server applications?
Are there any grid frameworks that provide ACL capabilities for accessing data in the grid (I'd be happy with some ad-hoc stuff, although complying to Java EE role concepts would be nice)?
This is my opinion on current state of open source distributed cache solutions (e.g. JBoss Cache and Infinispan). As a baseline I am using GigaSpaces commercial caching product. Let me know what you think about open source and proprietary cache products.
read more at: http://bigdatamatters.com/bigdatamatters/2009/09/infinispan-vs-gigaspaces.html