This is more of a general design question I guess...
I have an Ajax application that displays a table listing purchase orders.
Each order has a checkbox next to it
The idea is to check some of them, then press a button and a JavaScript function will start, pulling out the "checked" ones and passing them server side.
Right now the best I could come up with is giving each check-box a "value" attribute with the ACTUAL ORDER identifying number. So when they are collected, and passed to the controller, I can just use the values to query the database for the exact orders.
But I have a nagging feeling that this is not secure and not the most efficient way to do this.
So I would love to hear the better ideas.
Thanks in advance.
If the orders list can see only certain user, I dont see anything bad in your pattern.
In other hand, if someone could get this id and do request with it(for example - to delete order), you can always chack the permissions on server-side.
secure, in what way wouldn't that be secure ? does it matter the clients get to see those id's ?
Certain users shouldn't be able to pass any purchase order to the server ?
Yes, I think my last question is your answer.
And about it being inefficient; is there a performance problem with your approach ?
Related
I'm designing a program where you are registering for an organization. To reach the registration page however, you first need to login using another member's access key.
I have put in a switch statement assigning different passwords to different user names. I have then used an if statement to check if the password is correct according to the member entered and if not, to display a message indicating such. This works perfectly fine, however, if you input a member's name that isn't of the three I've hardcoded for, the code allows you to completely bypass the password field, basically making the security measures useless.
If anyone has any suggestions on how to fix this, I would really appreciate it. I'm assuming it's something simple but I am extremely new to coding, particularly the GUI and just can't figure it out.
I'm using NetBeans GUI builder.
Thank you!
Image of my code
I managed to change it slightly where that error no longer occurs. It is not completely perfect according to my intentions however this works for my needed functions.
If you have any further suggestions on how to improve this even more, I would still really appreciate it.
Thank you for all the assistance!
Adjusted code
(I also changed the messages to buttons for aesthetic purposes)
Particularly, what are all the dots and numbers at the end for.
Here is an example:
https://www.google.com/search?site=&tbm=isch&source=hp&biw=1366&bih=673&q=kale&oq=kale&gs_l=img.3..0l10.403.1120.0.1352.4.4.0.0.0.0.407.543.0j1j4-1.2.0....0...1ac.1.32.img..2.2.542.vC-f2Kfx-2E
It is a GET variables value, but why such a strange un-human readable syntax?
I assume they are using PHP or Java on the back-end.
What you are seeing is internal computer data, not exactly intended for normal human consumption, but there for a good reason. Also perhaps you are thinking, why would anyone want these ugly internal details displayed on the average user's screen?
When HTTP was invented the thought was that GET requests should be stateful, in other words, if I copy a URI from my browser and email it to you, and you browse to it, then you should see exactly what I saw. To make this work the GET data needed to be in the URI and not hidden from view. Thus the dirty details you are seeing. Back in the day they were thinking of simple GET queries, for example: http://www.somedomain.com/Search?Find=FooBar
However, as software has evolved more data needs to be passed with GET requests and unfortunately it is all visible in the URI. (Note that this also becomes a minor security hole because the average user can see some of the internals of web page production and easily tamper with it.)
What is needed is a hidden data passing method for GET type queries to clean up URIs when it is not necessary for these details to be present. A proposal for such an improvement to HTTP is in the process of being considered. It would involve adding a new method to HTTP similar to GET but with hidden data passing like POST.
I'm learning to program in Java and I'm wondering if there is a simple way to set a return point in a method in case a user decides they want to go back. For example, within a method, I ask the user to choose between one of three options:
1) Register
2) Search
3) Other
Let's say that the user chooses to register. This choice then presents them with two new options:
1) Register as User
2) Register as Admin
Let's say that they choose to register as an admin. They are then prompted to enter their information, but maybe halfway through they realize "Wait! I want to register as a user, not an admin!". Typing in "back" is also an option, and if they do so, I want to be able to take them back to the menu where they choose between user and admin, not all the way back to the beginning. Is there a way to do this? I know I could use loops, but my program is a bit more complicated than my example, so I would rather not if I can get around it. I'm looking for a way similar to the way you can name loops in assembly language, so that you can just say "go to this point" and it goes back without the user having to re-enter all the information that they did before the sub menu that they want to get to. (I realize that in my example they don't enter any info until that sub menu. In my actual program they do.)
Any ideas? If worse comes to worse, I'm not opposed to using a loop. Just figured I would ask!
Thanks so much!
I think using loops is as good a method as any. Two suggestions:
you might want to read up on the break-with-label statement; and/or
you might want to place each menu into a separate function to make the structure clear.
Let's say you have methods for each of these options. At any point if user wants to go to some option, just return from the existing method with some value which indicates the option user wants to jump to. From the main code, just go to the appropriate method depending on the option selected.
Also, each method may take input of the parent (id), so going back won't be a problem.
This way you can go back to the parent or to some other option from any point in your program.
I think you are looking at it the wrong way. You don't need to go back to a point in your code to do an undo or rewind, you need to create the logic to be able to change a decision and make it work with whatever data has been entered so far.
So for example, you would use a data structure to hold all the data that a user enters, and if he chooses to change his registration type, you'll be able to fill in his info from that data structure. He can also decide that the address he gave you is wrong and change it, you'll still want to keep all the data you got so far, regardless if he's changing from user to admin.
The point is, you are looking at this in a sequential way, as if code can only run forward and backward in a straight line, while Java and even assembly are not at all sequential, you can go in every direction, skip to some logical point in time, and jump back to where you were.
The description may sound like just a bunch of words so here is a more detailed explanation. I have a User object which is mapped to database table.
I want users to be in different roles. There will be a bunch of those - and they technically will be the same users in same table but to them will apply different roles. Say user in role A will have to have two fields as required, and will have to have certain restrictions to the length and contents on his password, as well as the time expiration of his password, etc.
While I can hardcore those rules I am very interested to find out of there is an other way to define the rules and may be store in database so it's easier to load/apply and the main idea - to change and update them -- without redeploying the codebase.
Technically the stupidest and straightforward solution is to implement class, serialized, store in db, then load, deserialze, call methods on it which will execute rules. The problem is in changes to the ruleset ( read "interface" of the rule class ) and that generally solution sounds like a hack.
Anytihing else? Any frameworks? Other approaches?
UPDATE: probably was not clear. say, I have class User.java
I need to define different rules say:
1. do we need to verify length of password, and what should it be?
2. do we need to require some properties to be required?
3. do we need to track login attempts for this user?
4. if we do track, how many login attempts allowed?
5. do we expire password?
6. if we do, then in how many days? or months? or weeks?
7. ...
and so on and so on.
so questions ARE.
- how do I define those rules and operate on User object WITHOUT modifying and redeploying code base?
- how do I store those set of rules?
Drools, jBPM, etc. do not seem like a fit for that task. But any advice would help!
JRuleengine is good I heard, sometime back I planned to use it for similar application.
There are many other Rule Engines though.
Well there are some good rules engines out there include jrules, drools I think is popular too. One thing to keep in mind is the relationship between a rule and the data it examines. After all you can have the rules in a word document, but when they execute they need examine data, and that is also a factor in choosing a rule engine or architecture. generally its if (a > b) then do y. Means you need to examine a and b in the rule execution. That is the real issue is how to get the parameters into the rule and engine.
Say, You have an application which lists down users in your application. Ideally, if you were writing code to achieve this in Java, irrespective of what your UI layer is, I would think that you would write code which retrieves result set from the database and maps it to your application object. So, in this scenario, you are looking at your ORM / Data layer doing its thing and creating a list of "User" objects.
Let's assume that your User object looks as follows:
public class User {
private String userName;
private int userid;
}
You can now use this list of "User" objects, in any UI. (Swing / Webapp).
Now, imagine a scenario, where you have to list down the userName and a count of say, departments or whatever and this is a very specific screen in a webapp. So you are looking a object structure like this:
public class UserViewBean {
private String userName;
private int countDepartments;
}
The easiest way of doing this is writing SQL for retrieving department count along with user name in one query. If I you to write such a query, where would you have this query? In your jsp? But, if you were doing this in a MVC framework, would you move this query to your data layer, get the result set, convert it to UserViewBean and send it to your jsp in request scope? If you write queries directly into jsps/if you are making use of connections directly in JSP, isn't that a bad practice?
I know, some of you might say, 'hey, you got your object composition wrong! if department is linked to user, you would want to create a list of departments in your User object' - Yes, I agree. But, think of this scenario - Say, I don't need this department count information anywhere else in my application other than this one screen. Are you saying that whereever I load my User object from the database, I would have to load a list of dependency objects, even if I won't be using them? How long will your object graph get with all the relational integrity? Yes, I do know that you have ORMs for this very reason, so that you get benefits of lazy loading and stuff, but I dont have the privilage to use one.
The bottom line question here is:
Would you write sqls in to your JSP if it serves just one screen? OR
Would you compose an anemic object
that caters to your view and make
your business layer return this
object for this screen - just to make
it look a bit OOish? OR
irrespective of what your screen
demands, would you compose your
objects such that an object graph
is loaded and you would get the
size of that list?
What is the best practice here?
I would never put SQL in a JSP. I would use Spring MVC or Struts controllers, or servlets to contain all of that type of logic. It allows for better error handling among other things (you can forward to error pages when queries fail).
If you really must do this, use the JSTL SQL tags.
Personally, I take a simple pragmatic approach. If I was writing screen that just displays a list of users with their deparment count, so that the entire code is maybe a page, and I don't expect this code to be used on any other screen, I'd probably just throw it all in the JSP. Yes, I know there are all the MVC purists who will say, "business logic should never go in a JSP". But aside from a dogmatic rule, why not? What would it hurt in a case like this?
If I found that I had two screens, maybe one where I had to simply display the list and another where I had to do some additional processing on the list, then I would certainly pull the common code out into a class that was called from both places.
I believe that the criteria should be: What produces the most maintainable code? What is shortest and easiest to understand? What produces the least linkages between modules? etc.
I adamantly refuse to accept the principle: "In some cases this approach leads to problems, therefore never use it." If sometimes it leads to problems, then don't use it in the cases where it leads to problems. Or worse, "Somebody wrote it in a book, therefore it cannot be questioned." Sure, there are some rules that are valid 99.99% of the time, so it gets to be pointless to check if this particular case is an exception. But there are lots of rules that are good 51% of the time and people leap from "mostly" to "always".
Would you write sqls in to your JSP if it serves just one screen?
In a prototype, just as a quick hack - maybe. In any other situation, not to mention a production environment - NEVER.
Use a proper MVC framework to separate business logic from presentation.
I am not even sure that JSP should be used, but for trivial applications. If you really have to use them, use MVC pattern or encapsulate your logic in a JavaBean.
Have a look at JPA which allow you to do object manipulations which then is persisted in the database
I wouldn't put SQL in a jsp for fear of forgetting it in future maintenance. Think of the poor guy maintaining your code-- poor guy = you in 10 months or whenever the database is restructured-- and at least put all SQL in the same general region.