Want to design a form where user fills incremental forms, like first personal info , then click Next and fill employment info click next and so on.
Using AngularJS, do i need to call DB save with every Next button OR Just hiding old section and showing next section will work. If i go with ng-hide\show, values in the old input fields are lost obviously.
Please suggest.
You can use state management like ngrx or any Subject provided by rxjs to keep your state alive. Your data won't be lost. Eg : Use Subject or BehaviourSubject to pass/store the data. Be careful ngrx is a good state management, but not mandatory. If you don't know ngrx, use Subject. Because Subject is pretty much easier than ngrx and ngrx makes your project mess if you don't handle it in a proper way.
Related
What I mean by 'conditional' privileges is, for example: Say we have Event e. The user who CREATED Event e should be able to delete Event e and invite additional users to Event e, but only that user.
From tutorials I've seen, permissions and roles seem static, for example:
Doctor has a role doctor, with permissions x, y and z, but that is it...pretty static.
Is there a simple way to conditionally manage permissions with Spring Security?
Or would this be something better suited for the front-end? For example, the view would show a 'delete event' button only if the resource data for that particular Event confirms that the Event creator's ID is in fact the same ID stored in session memory/keychain/whatever for the currently logged in user, type of thing.
Thanks
First of all,
Or would this be something better suited for the front-end?
...show a 'delete event' button only if...
NO. Not as a reliable line of defence, no.
Well that probably depends on a tech stack, architecture etc, but as a rule of thumb, you shouldn't do it. I didn't write servlets/jsp, but I used spring security in a rich client (swing) application and even though we had all the control (I mean, we could guarantee that user cannot access some function no other way than clicking a button), we secured our models, not the gui.
You shouldn't be able to call Entity#delete no matter how you call it - via button click event or calling it directly in a test. In case of web application, imagine you don't display a button, but an attacker knows that button leads to example.com/entity?action=delete URL or something like that, he could access it directly even if you don't render the button.
With regard to the main question, spring security, roughly speaking, has two parts: RBAC and ACL. What you need seems to be the ACL part. Read some howtos and articles about domain security, it's a pretty complex stuff, but it can be suited for your needs for sure (with some effort, of course). What you described in a first paragraph may be achieved easily because every object has it's owner and it can be exploited.
Also, here's a good advice.
Edit: just to clear things up for future visitors. Point was: there should be some logic on the front-end, but it must not be the only security logic. Of course there's no need to clutter UI with buttons leading to functions you can't access.
We are trying to build a GUI framework using GWT. We are finding it hard to implement the cancel functionality in the framework.
Required feature is this:
We have CRUD screens which have pop-ups, grids and so on. When the user changes anything in the GUI and then clicks on cancel() he should be given a notification message saying that something has changed.
Approach that we have tried:
Currently we are trying to keep a hashmap of key vs value of the entire pojo object and trying to compare it against the model which gets updated as and when user changes something. But this is adding lot of unwanted code in every pojo and not working as expected when user adds data directly from the backend.
Is there any elegant way in achieving this functionality? Kindly note that *we are not using Editor framework of GWT *(https://developers.google.com/web-toolkit/doc/latest/DevGuideUiEditors) in our application.
Example:
Suppose I have a pojo like this:
public class Person {
List<Address> address;
PhoneNumber phoneData;
// and so on along with getters and setters
}
How will I write a generic clone method for this? And even if I manage to do that somehow that will lead to lot of code in every pojo (our application has hundreds of them) which doesn't seem right.
Please note that, our pojo gets updated as soon as something is changed in GUI to achieve live binding.
So you have "Save" and "Cancel" buttons in your form?
I would recommend you to change the concept. Update your object properties immediately as user edit them (as in GMail, JIRA and many other modern applications) in an OnChange event handler.
Save all updates to the session stack as UpdateAction objects and let the user undo every single property modification calling UpdateAction.undo() method.
The benefits are:
this design is much more user friendly than "Click "Edit" - update - click "Save"" scenario.
You don't need separate view/edit forms/popup dialogs - just a single form for both viewing and editing.
I'm building a page that has a search box that will populate a grid on the same page. There is also a button the user can select to bring up a "window" (JQuery UI "pop-up" in the same page) that lets the user configure said grid.
These are two separate forms but I don't want what was submitted as part of one to undo the other (so when the user submits to change the grid layout the search needs to re-run as well.
I'd rather not store things in session for this since that brings with it its own issues (search results may be large, shouldn't be saved when the page is re-entered later, etc.).
I've considered doing "one large form" (i.e. surrounding all the inputs) for the entire page that is backed by a form backing bean. I would then use which button is clicked to determine the action to take. There will eventually be other buttons on the page as well to add more functionality. This would be similar to how .NET (non-MVC) handles things.
I'm interested in how others may have solved similar challenges. Are there potential issues with my approach that I'm not seeing? Better ways that work with the framework?
What do you mean with:
but I don't want what was submitted as part of one to undo the other
. Are you referring to posting the form and loading the whole page, which in turn will "reset" the other form?
If that is the case I would still keep one page with two forms and make the posts using Ajax (as you may know jQuery makes this a breeze). Upon receiving a response for either call you will need to update the other form accordingly.
Note that you may still have your forms in two separate views if it helps keeping the code clean and then pull their html with Ajax calls into another view. But my point is that at the end I would still keep both in one page since it sounds like they depend on each other so updating one when the other changes may be easier this way,
Let me know if I misunderstood your question.
We are trying to implement some flow control in Play, kind of a wizard with several steps. What is the best practice to do it in Play?
Requirements we have:
Should allow multi-step flows, like step1 -> step2 -> step3 -> step4 -> finish
Should be able to change order or steps depending on context, so if user selects a checkbox on step2, flow should be step1 -> step2 -> warningStep -> step5 -> finish
Ideally needs support for "Back" button to return between steps
The problem we have is that any single step in flow doesn't know where it should redirect next and since Play session is very simple, it won't help here much.
Here is the solution we currently have:
Store Flow steps in database in user object with #OneToMany public List<FlowStep> flowSteps
Provide methods in user model to add/remove/skip and change order of flow steps stored for this user
Implement steps normally, with form action leading to "doStep3" controller etc
Implement "Flows" controller that uses #Before and #After interceptors to correctly redirect to next step after current step is processed and no validation errors found
Added Flows.next() controller that redirects to next step (used for "Skip" button href)
What are the disadvantages of this solution? Is there any better way (maybe some Play built-in methods) to improve it?
What you want is a finite state machine. To implement it, you'll need a class that knows all the possible transitions between steps. Then you can provide to it the current step and any relevant input, and it will return the output (where the output is the view to render next).
Then you use render to redirect the user, as in:
render("my/view/path.html", myparams);
This is not the only option, and storage of the transitions will depend on how complex you need them (can be hardcoded for simple scenarios, maybe stored in database for more complex ones), but it should work.
As Play is stateless you'll need to keep the information in the database (for complex scenarios where you need to take in account information for several steps) or, if the relevant togles are just a few, store them in the cookie itself.
I would avoid using #Before/#After as you are coupling the state machine to the controller. Ideally you want them to be idnependent, with the state machine returning only transitions that you can translate later into view paths. That will simplify changing transitions.
If the scenario is not extremely complex, I would not even bother to store them in the database. If you want it reusable and extremely flexible, then do it, otherwise it may be simpler to just "hardcode it".
Did you check this section in the Play documentation (a very quick read):
http://www.playframework.org/documentation/1.2.4/model#stateless
It lists the options you have for exactly what you are asking.
You can try to use Play Cache mechanism as pseudo session to store the validated steps instead of handling in the database. Using Play Cache would be a simpler solution
I have a Java web application which stores some data in the session. The data in the session changes as the user interacts with the application (e.g. flow is managed by a controller, each controller has several form pages, on each form page some data is updated in the session and flow goes to the next form page).
The problem is that some users are opening more than one tab to the application, each tab with a different step in the flow. At this point data in the session is messed up since the tabs share the same session (app uses cookie managed sessions).
Telling the users to use different browsers to avoid sharing the same session id (e.g. one Firefox window and one IE window) is not an option since surely at some point somebody will forget to do this and instead use tabs, thus messing up their data.
Adding some verifications that detect that another flow is requested from another tab and display a message to the user saying this is not allowed is not an option either since it pisses of the users and we don't want that do we? :D
The fact is that using another tab is useful for the users because they are more efficient in what they use the application for, so I am keeping this option. But the question now is how best to manage the one session data for the more tabs?
What I thought of, was to have the controller generate a token when it starts the flow and pass this token to each form page which in turn sends it back to identify itself. If another tab requests the same controller action when there is an ongoing flow then generate another token and pass that around.
Basically, I want each flow to have a token and inside the session I won't just keep one set of data but have a set of data for each token and then match requests based on the token.
Now the problem is that this approach will need a lot of rewritings to the application and I was wondering if there is a best practice for managing such a situation or can someone suggest other approaches. I am open to ideas.
Have you encountered this situation? How did you handle it?
This is usually done by assigning a windowId for each tab/window and passing it on each request. Jsf supports this via orchestra. Spring mvc will support it in the next version.
I recently needed this for a simple case, so I implemented it myself. Took half an hour. However, my scope was very limited:
pass a windowId with each request, and return it back for the next request. The first time - generate it.
for any attribute you want to store in the session, put a Map<String, Object> where the key is the windowId
This is exactly what Seam was created to handle. In Seam there's a concept called a Conversation which basically does exactly what you are explaining. Conversations are basically are a way to divide the Session into many pieces that can expire at some timeout. You can look at the source code for org.jboss.seam.core.Manager class to see how it's actually implemented and get inspired ;)
Depending on the complexity of your application, you may want to investigate implementing tabs within your application. This gives you wholesale control over the flow, while still providing users with the functionality they want. I'd argue it's, bugwise, the most robust solution, since you won't have a dependency on the way the browser handles sessions, minimising the number of "known unknowns".
Of course, there'll be potentially a large upfront cost to this, depending on how your application is structured. Without more information about your app, you're the best placed person to decide.
You can also try to wrap your application inside Adobe Air
And then limit your web application to be only accessable from this air. By doing this you dont need to consider the web browser fragmentation and their unique behaviour.