public variables can be shared by multiple users?

I have public static variables in some of my classes...think that there are 2 pages...

page1:sets that public variable..

page2:reads that public variable...

so the 2. person can read 1. person's variable by directly calling the second page or he gets null,error etc:?

its important for the security!generally are the values are session protected?or user must handle this security by coding correctly...

thank you

[450 byte] By [netsonicca] at [2007-10-3 4:33:45]
# 1
> so the 2. person can read 1. person's variable by> directly calling the second page or he gets> null,error etc:?person 2 can read person 1's variable if and only if they are sharing the same running instance of the jvm
tjacobs01a at 2007-7-14 22:37:22 > top of Java-index,Java Essentials,Java Programming...
# 2
It would be swell if instead of crossposting you could ask a question that makes some sense. Are you talking about Servlets here? What is in fact your question and your concern? Can you phrase without buzzwords?
cotton.ma at 2007-7-14 22:37:22 > top of Java-index,Java Essentials,Java Programming...
# 3
my question and my concern is clear as my english lets to explain...i am talking about the public static variables on a servlet and concerning about the security if people can reach other user's values
netsonicca at 2007-7-14 22:37:22 > top of Java-index,Java Essentials,Java Programming...
# 4
Yes this sounds like a very bad idea.
cotton.ma at 2007-7-14 22:37:22 > top of Java-index,Java Essentials,Java Programming...
# 5

Actually, neither your question nor your English are particularly clear.

However, if you're asking what I think you're asking, then, yes, the variable can be seen by multiple "users." I put that in quotes because there really isn't a concept of "users" or "people" here unless you build in such a layer. It's really requests that we're talking about.

Servlets should not usually have member variables. The reason is that usually only one instance of your Servlet implementation exists, and it processes all requests for that servlet. This is more a data validity issue than a security one. Security comes in at the layer where you build it (or use a 3rd party library), but a side effect of this can be compromisd security. The access levels--public, private, etc. are NOT intended for security purposes, however.

Now, if that servlet's doGet(), doPost(), service(), or whater methods create instances of some other class, then, no, other requests cannot see those objects, as long as the references to them stay local to the servlet's methods, and don't get put into the servlets member variables or an application context.

jverda at 2007-7-14 22:37:22 > top of Java-index,Java Essentials,Java Programming...
# 6

> Actually, neither your question nor your English are

> particularly clear.

>

> However, if you're asking what I think you're asking,

> then, yes, the variable can be seen by multiple

> "users." I put that in quotes because there really

> isn't a concept of "users" or "people" here unless

> you build in such a layer. It's really requests that

> we're talking about.

>

> Servlets should not usually have member variables.

> The reason is that usually only one instance of your

> Servlet implementation exists, and it processes all

> requests for that servlet. This is more a data

> validity issue than a security one. Security comes in

> at the layer where you build it (or use a 3rd party

> library), but a side effect of this can be compromisd

> security. The access levels--public, private, etc.

> are NOT intended for security purposes, however.

>

> Now, if that servlet's doGet(), doPost(), service(),

> or whater methods create instances of some

> other class, then, no, other requests cannot

> see those objects, as long as the references to them

> stay local to the servlet's methods, and don't get

> put into the servlets member variables or an

> application context.

thank you this is what i exactly wanted to learn...i have also tested it with my test codes and same things seen parallel to your explanations...

netsonicca at 2007-7-14 22:37:22 > top of Java-index,Java Essentials,Java Programming...
# 7

> Now, if that servlet's doGet(), doPost(), service(),

> or whater methods create instances of some

> other class, then, no, other requests cannot

> see those objects, as long as the references to them

> stay local to the servlet's methods, and don't get

> put into the servlets member variables or an

> application context.

But he said that they're static and public.So those values could be seen and possibly modified across instances.

paulcwa at 2007-7-14 22:37:22 > top of Java-index,Java Essentials,Java Programming...
# 8

> > Now, if that servlet's doGet(), doPost(),

> service(),

> > or whater methods create instances of some

> > other class, then, no, other requests

> cannot

> > see those objects, as long as the references to

> them

> > stay local to the servlet's methods, and don't get

> > put into the servlets member variables or an

> > application context.

>

> But he said that they're static and public.So

> those values could be seen and possibly modified

> across instances.

I think that's what I said, innit? If it's a member variable of the servlet, it can be accessed by multiple requests, and therefore servlets shouldn't have member variables. If it's local to the doXxx method, it won't be visible across requests.

I guess I missed the "static" part. That only makes a diference if there happen to be mutiple instances of the servlet, which is a) unusual and b) not something you can generally predict or control.

jverda at 2007-7-14 22:37:22 > top of Java-index,Java Essentials,Java Programming...
# 9

Well, suppose you have a single servlet instance. It creates an object of a class called "Moose".Moose contains a static field named badger. The servlet modifies (or causes to be modified) badger via manipulation of its Moose instance. It then throws the Moose instance away.

Then the same single servlet instance is invoked again. The second time through it creates another Moose instance. Won't that instance see the modified version of badger?

This can be a good thing, of course, but from the OP's question I get the impression that he may have gotten hung up on this.

paulcwa at 2007-7-14 22:37:22 > top of Java-index,Java Essentials,Java Programming...