I have existing Java application that is using Acegi for authentication/authorization. Our new web interface would be preferably written in Django. I would like Django to maintain users - registration etc. Django would either share or update Acegi authentication data so the older application still works and users don't have to use two sets of credentials (maybe even share authentication cookie). I was wondering if someone was already dealing with similar issue and if yes which approach was chosen.
Thanks
Just remember whatever you do with Django, it is still Python, therefore just because Django doesn't have it/doesn't do it that way, doesn't mean you can't. Also, from another point of view, there is nothing stopping you using bits of the Django framework from outside the traditional Django application.
I don't particularly like the admin interface to Django although I do use Form and ModelForm a lot outside of it. I actually implemented my own authentication system - all you need are functions that let you log in/out etc and an interface to that data. It (users/groups etc) doesn't have to be represented as a Django model although that's what I did for ease. There is nothing stopping you hooking in another ORM or writing your own for acegi. Alternatively, if writing your own layer is simple enough, do that.
I'd recommend hooking into the context processors for Django and the Django middleware and library-ising your work simply because it'll make re-use a breeze and it will act in a similar manner to the existing authentication framework. Here's an example context processor I use to allow me to write {{ username }} in my template without having to get it out of every request object in every view method:
def Authentication(request):
if AuthenticationCheck(sess=request.session, timeofaction=datetime.datetime.now(), ipaddress=request.META['REMOTE_ADDR']) == True:
return dict(username=request.session["username"])
else:
return dict(username='')
Also, Django Middleware Documentation
Related
There are already a few posts on SO discussion whether this architecture is a good idea or bad idea. For many reasons within our company including the existing programming talent, we've decided to use Java for the backend and PHP for the front end. Our objective is something like...
Java - Models/Controllers
PHP - Views
We're working on building a prototype of the interaction between Glassfish and Apache. One thing we're still working on is when a user visits http://domain.com/login.html and they login, that login will be sent to the Glassfish controller which exists somewhere like /login.java. We can do that no problem, the trouble is getting the view to be rendered at that URL.
Has anyone does this with PHP or any other technologies?
Have you considered setting up a soap/rest server in java and having PHP talk to that? I imagine that would be much simpler than what you're trying to achieve.
I am sorry to bring this up but it seems like it would make things a lot simpler to stick with just one of these languages. If you are using PHP to add more logic into your view, it might be worth taking a look at Velocity. It allows you to access and create variables, iterate through lists, use conditionals, define macros, make method calls, etc. This seems like it might make things much cleaner. However, it is usually a good idea to try to keep as much logic out of your templates as possible.
If you would like to use PHP because that is what is required I would suggest taking a look at using web services to communicate. Take a look at Googles GSON library. It is really nice tool (on the java side) for mapping JSON Objects to your model (and vice versa).
On your front-end, it might also be worth taking a look at Backbone. It is a tool that makes it simple to mock up your model Objects and bind events to them, or add tie them directly to fields, etc.
I've had first hand experience at two companies that use the Java Service layer and PHP Client layer technology stack, although it was not used exclusively. To clearly separate the layers a well-defined JSON REST API was built so each layer had a contract it could code to.
The Java layer used SpringMVC in-between the persistence layer to generate JSON views with well-defined routes (i.e. URL structure) in order for the PHP layer to GET/PUT/POST/DELETE resources.
Regarding the login issue specifically, there were actually two Java services, one specifically for login/logout and the other for the regular backend.
When visiting /login which I assume would be a .php file. A submit of the login <form> to the "Login" service resulted in a session cookie being added but also an encrypted "user ID" cookie. The encrypted cookie could then be used to protect access to the Java Service layer for the product. Each REST request from PHP to Java would have access to the cookie, and the Java layer could then decrypt the "user ID" and respond to the PHP REST call if it was valid. The Java layer would then have access to the real user ID in order to return user-specific data from the persistent store.
I need to design a simple web app which has only 3 pages, namely log in, a page to enter new data and view previously entered data, and one to manage what the users entered. There are a few more constraints, but that's the general idea.
I was wondering what you think of the following design:
one single (!) static html page, with a little bit jquery render and communication logic
a RESTful web service (Jersey, for example), which would accept data send by jquery and process it (java-json conversion would be ensured using jackson)
a java model persisted in a database
basically, the HTML + CSS would be the view, jquery + jersey my controler, and then the java model. Everything would be done using good programming principles, etc.
From what I understand, this would allow to very quickly develop my stuff, have a very modular design, be highly compatible (regular DB-java-jquery-html), be easily able to scale out if needed, and have blazingly fast response times.
Since I'm not out of college yet, and I'm on my own to do this (thus have no one to talk about on this design) I'm not sure how good my design is. Namely, I wonder about the following questions:
Are there any flaws I am overseeing?
Am I over-engineering/complicating this?
Is there any security flaw I didn't see (from the design, not from the implementation)
Thanks;
P.
Your design is pretty good. You can have a look at my proof of concept that works exactly as you've design, except that it uses jqGrid to handle all CRUD operations and has a mocked DAO.
Security is not an issue, HTML and JavaScript can be served anonymously, but all REST operations need to be secured. You have to login first to obtain JSESSIONID cookie and pass it with every AJAX call (this should actually happen automatically).
This is a good design. In fact, you can just release your API this way, the way Facebook, Twitter do. All you need to do is to explain what your RESTful service expects and what returns. And anyone can develop an app over it. So, this is good part. Lets answer your specific questions:
Are there any flaws I am overseeing?
No. In fact, these are simple CRUD operation, pretty standard stuff. You could get the same done quickly (called fast flash to bang), if you use a framework (Wicket, Play!, Struts-2) that handles many things for you. What you are doing is developing components by your own.
Am I over-engineering/complicating this?
Yeah, a little. If it's just a college project, and you're in control. I would suggest just go with a web-framework that will be the fastest thing, probably. They might hide a lot of implementation details that you may have to do with your current design.
Is there any security flaw I didn't see.
Nope. As long as you are taking care of authentication and authorization on URLs that need it, you are safe. You could consider HTTPS, but that's too much.
I have created a Java desktop application, and have decided to turn it into a web app. The app carries out basic statistical tests on data and is fairly small around 1000 lines for main functions.
So far i have created the interface using Jquery UI with all requests sent via Ajax. I am now ready to start developing the back end, the plan was to code basic Servlets to link my interface to the core Java classes.
Would this be a ok approach for a small app? or is there a specific framework i should follow?
I have looked over struts but it seems massive and also spring mvc, but again i am not sure if that would work with my one page interface.
(This whole app is for learning purposes, so i am always willing to extend my knowledge, however looking for that doesn't take too long to learn.)
I've started building my webapps as Jersey + Jackson backends, offering up a REST API to a static HTML/JQuery/Angular front end.
It's worked out to be really scalable as you can heavily cache the front end and stick it on Amazon Cloud Front, and the backend can scale horizontally as needed. The need is much lower than traditionally as it's only actual operations that hit the Java server.
If your program is only 1000 lines, you will probably spend more time learning a framework then the time it will save you. You can make a well designed MVC server without a fancy framework.
There are some APIs that might be useful though, like a logging API or Hibernate if you need a database.
I agree with the other answers that REST is a good idea.
A framework can get routine off you shoulders. The JAX-RS mentioned above will handle URL-to-service mapping and conversion from JSON to your types and back.
Now, what to choose is entirely up to you. For a small application, the time you spend learning the framework can be so huge that you won't care about the benefits any more. On the other hand, frameworks give you a code which is easier to read and thus easier to maintain.
I would suggest to expose a RESTful API using some JAX-RS framework (e.g. Jersey) instead of pure servlets.
Also, as a representation I suggest to use JSON, which is very conveniently used in Javascript with/or without JQuery .
We are green fielding a mobile web app against an existing Java web app --the database of that app, at least.
We are only using the database of the original app because the original app is built on a custom ORM solution and Struts 1.1 that is showing its age. So this is going to be a bit of a proof of concept for what can be done with modern tools.
We have decided to utilize JQuery mobile on the front end to leverage device cross compatibility. On the back end we are going to go with JPA for now...maybe moving to Hibernate down the road. But we'd like to expose our model with a RESTful service to kill two birds with one stone (the original app interfaces with a number of third party's that we'd like to give access over a simple REST interface that happens to have a lot of overlap, data wise, with the mobile module.)
So, the question is which controller layer will best tie the JQuery mobile front end with the RESTful back end?
We'd like a controller framework that:
Is not too intrusive. i.e. we don't have to lock ourselves into that particular implementation because of hard set dependencies spread all over the code.
Is annotation based or heavy on convention over config. or both so we are not writing reams of XML glue
Doesn't bring along cruft that we won't be using... i.e. it sticks to the controller layer as much as possible
Can handle REST from one end and AJAX from the other without too much trouble
The larger the community the better
The simpler to get up an running without compromising any of the other points, the better.
We've begun exploring Struts2, SpringMVC, Stripes, Play! etc. but I am hoping for some sage advice from the erudite SO community to help narrow the field.
If you need anything clarified, I will be happy to do that.
It seems to me that you're searching in the wrong direction.
Your Java App is producing JSON/XML through REST web services.
Your jQuery client is consuming those web services to publish them to an interface
You seem to search a controller server side. Why? Producing REST web services is not the only goal of a REST server?
Take a look at BackboneJS — it's not the only one in the category, but the one I know better — it's a client-side controller. It fits perfectly with jQuery and allows to access REST resources with HTTP verb — GET, PUT, DELETE, POST — in a compact and generic way.
If you choose so, I'll help you further.
I have chosen Ext-JS to develop the UI for my next application. I am wondering what is the best way for Ext-JS to interact with my server.
Should I use plain JSPs which return a JSON response? Should I use DWR or Jabsorb which provides direct remoting with backend java code. Any other solution?
I am more concerned about performance and nothing else.
You can certainly use plain JSPs or servlets, manually handling your requests and forming JSON responses. You'll make life easier on yourself using DWR or something like it to handle the plumbing for you, and the performance shouldn't be noticeably different.
Current versions of Ext JS use the Ext.Direct stack for integrating supported back ends into the UI data layer, making it much simpler to bind components like grids and forms to your back end services. Here is a grid sample that demonstrates such remoting. Here is the Ext.Direct forums -- you should have a look at what others are doing. Look at this post to see what Ext.Direct providers are currently available for Java.
Again, you can certainly make your calls manually from Ext using Ext.Ajax directly (or using the standard Store methods for making calls), but the Ext.Direct stack can make it much easier to integrate everything together.
we'r using the extdirect library for Spring MVC 3 in our Company and it works fantastic !
Extdirectspring
You can ask me when you've troubles configuring it.