Tom Ziemer wrote:
Thanks to everybody who replied to my original post. I am currently
using spring/acegi and it's working great - as long as you use Spring to
create your beans:
// Spring - works like a charm: security via acegi and transactions via
proxies
this.entityManager = (IEntityManager)
Thanks to everybody who replied to my original post. I am currently
using spring/acegi and it's working great - as long as you use Spring to
create your beans:
// Spring - works like a charm: security via acegi and transactions via
proxies
this.entityManager = (IEntityManager)getBean(SpringBean.M
Paul Benedict wrote:
Spring can give you method-level security if you're interested in it.
http://acegisecurity.org/
It will use AOP to proxy your classes and make sure any thread has the proper
credentials to
access your code.
And that's how to re-invent the wheel in chrome ;-) Seriously, P
The Java security manager infrastructure. That's what it's there for :-)
L.
Frank W. Zammetti wrote:
What is so objectionable about it? If you think securing a method is a
good idea (I'm not sure I do, but let's assume for the sake of
argument), why is this answer "square"? :) I don't doubt
LOL! Wunnerful! And I agree.
> -Original Message-
> From: Josh McDonald [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 16, 2006 7:04 PM
> To: user@struts.apache.org
> Subject: Re: [OT] Hiding methods
>
>
> Strewth! I just went back and read this thread.
netsql wrote:
> Ahh... that's what code defensively means. :-)
Programming for job security.
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Ahh... that's what code defensively means. :-)
Some threads are just more fun.
.V
Frank W. Zammetti wrote:
What's wrong with the implementation?
And, if it took my replacement a week to figure that out, I would hope
he'd have a replacement shortly thereafter :)
Frank
What's wrong with the implementation?
And, if it took my replacement a week to figure that out, I would hope
he'd have a replacement shortly thereafter :)
Frank
Josh McDonald wrote:
It's not the idea we're objecting to so much as the suggested
implementation.
But the problem is no matter h
Spring can give you method-level security if you're interested in it.
http://acegisecurity.org/
It will use AOP to proxy your classes and make sure any thread has the proper
credentials to
access your code.
Paul
__
Do You Yahoo!?
Tired of spam?
Josh McDonald wrote:
> It's not the idea we're objecting to so much as the suggested
> implementation.
>
> But the problem is no matter how nice your implementation is, you've
> still got to maintain a list of "allowed" classes, which is fine for
> you. Unfortunately when you've moved interstate,
It's not the idea we're objecting to so much as the suggested
implementation.
But the problem is no matter how nice your implementation is, you've
still got to maintain a list of "allowed" classes, which is fine for
you. Unfortunately when you've moved interstate, and your replacement's
replaceme
Because knowing the calling object might not be sufficient... you may
want to know the exact method that called, and further, you may not want
to introduce the extra parameter, which changes the public interface.
Mind you, I AM NOT saying this is a good idea or anything, but I am a
little surp
What is so objectionable about it? If you think securing a method is a
good idea (I'm not sure I do, but let's assume for the sake of
argument), why is this answer "square"? :) I don't doubt there is a
better answer, but what is it?
Frank
Laurie Harper wrote:
Frank W. Zammetti wrote:
I sa
Question: How is the basic concept any different from method-level
security on an EJB? Aren't you in essence putting security on a public
interface?
I personally would tend to not block access to method either, by
whatever method, as was originally asked about... but is it really as
evil as
The short of it is you can get around public, private etc with
reflection anyway, so why slow down the entire system just because
you're under the incorrect assumption you can "force" api consumers to
do anything?
If it's that flaming important, sick the lawyers on 'em. That's what
they're for.
Strewth! I just went back and read this thread... Throw an exception and
check to see if you like the caller That makes baby jesus cry.
If you have public methods you don't want people to call, ask them not
to. If doing what you ask them not to causes exceptions and their
program not to work,
It sounds like it is time you move to the Spring Framework.
[1] Do not allow your DAO to manage transactions.
[2] Transactions are managed by manager proxies.
[3] Transaction Managers are configured to say which methods start a
transaction.
[4] Transaction Managers are smart enough to know, wi
Wow.
Why not
method(args, this);
so you know the calling object.
or better version.
register(this);
method(arg);
Plenty of OO designs.
Or just don't make it public, there are 3 "modifier" choices left other
then public, including package/friend.
I would just expose an
Frank W. Zammetti wrote:
I saw a very similar question asked a few months back in a general Java
forum, and I suggested an answer that I've never had the chance to
actually try out... the theory is interesting though...
In the method you want to "protect", immediately throw an exception and
catc
Just a quick hacked-together test:
public class test {
public static void main(String[] args) {
m1();
}
private static void m1() {
m2();
}
private static void m2() {
Throwable t = new Throwable();
t.fillInStackTrace();
StackTraceElement[] ste = t.getStackTrace();
[EMAIL PROTECTED] wrote:
> I don't think you'd have to throw and catch it. I think it's sufficient
> to create an instance of Throwable to check the stack trace.
>
That is correct.
Before you could get the array (or whatever it is) of the stack trace
we'd 'print' the stack trace to a string th
Hey yeah, I think your right! It *still* may be a little heavy, but one
would definitely think less so. Off to play for a few minutes...
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Michael Jouravlev replied
> On 2/16/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> > In the method you want to "protect", immediately throw an exception
> > and catch it. Then, parse the stack trace and see who the
> caller was.
> > If it's not a class you want to have access to the method
Throwing exceptions has always been a somewhat expensive operation, so
certainly where high performance is a concern I wouldn't even think of
doing this. But, if it's a handful of especially sensitive methods that
aren't called all the time, it might be acceptable. Some quick and easy
tests shoul
On 2/16/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> I saw a very similar question asked a few months back in a general Java
> forum, and I suggested an answer that I've never had the chance to
> actually try out... the theory is interesting though...
>
> In the method you want to "protect",
I saw a very similar question asked a few months back in a general Java
forum, and I suggested an answer that I've never had the chance to
actually try out... the theory is interesting though...
In the method you want to "protect", immediately throw an exception and
catch it. Then, parse the stac
Tom Ziemer wrote:
Hi,
I have got a question quite unrelated to Struts: My app. is pretty much
layered, meaning, I have Hibernate, on top of which there are
SpringDAOs, on top of which are Managers that represent my business logic.
Now I wonder, if it is possible, to *hide* (maybe with annotatio
Hi,
I have got a question quite unrelated to Struts: My app. is pretty much
layered, meaning, I have Hibernate, on top of which there are
SpringDAOs, on top of which are Managers that represent my business logic.
Now I wonder, if it is possible, to *hide* (maybe with annotations?) my
DAOs from al
28 matches
Mail list logo
