Re: CryptedUrlWebRequestCodingStrategy + WebRequestCodingStrategy = resource URLs are not encrypted (bug?).
ok, added WICKET-2731
Antoine
On Thu, Jan 21, 2010 at 4:52 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
not sure that is possible currently. the aliasing only works on a per
class level. see SharedResources.putClassAlias().
you can add an rfe to have it enhanced.
seems like a quiet arbitrary requirement, especially when it comes to
security. an fqn does not give anything away security-wise.
-igor
On Thu, Jan 21, 2010 at 1:18 AM, Antoine van Wel
antoine.van@gmail.com wrote:
What can you do if you need to enforce that no fqn's are ever
generated in (resource) paths?
Best I can think of now is putting a breakpoint in the resourceKey
method where the fqn is retrieved, and then stepping through your full
webapp - which is a rather poor solution. Any other ideas?
Antoine
On Mon, Jan 18, 2010 at 5:18 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
the original design goal of the crypted strategy was to only encrypt
what the user sees in the url bar. since they never see resource urls
there was no reason to encrypt those.
re fqns, you can add class aliases into SharedResources to hide those.
-igor
2010/1/18 Sergejs Olefirs sergejs.olef...@parex.lv:
Hi,
I started using Wicket rather recently. As part of our security
considerations, we do not want immediately expose the underlying
framework(s) we are using, so we went ahead with URL encryption. We used
standard approach as described in examples:
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor(){
protected IRequestCodingStrategy newRequestCodingStrategy(){
return new CryptedUrlWebRequestCodingStrategy(new
WebRequestCodingStrategy());
}
};
}
Unfortunately I later discovered that this approach doesn't encrypt
resource
URLs, e.g. from:
CSSPackageResource.getHeaderContribution(..);
or
link.add(new Image(logoImage));
What's worse such resource references include FQN of related classes.
After some investigation I found out that the problem is that
CryptedUrlWebRequestCodingStrategy only encrypts arguments string of the
URL
and WebRequestCodingStrategy encodes resource references as path rather
than
as argument.
I was able to get around this by subclassing WebRequestCodingStrategy and
overriding methods:
addResourceParameters(..);
encode(RequestCycle requestCycle, ISharedResourceRequestTarget
requestTarget);
to use arguments rather than path as resource reference.
However I'm unsure as to original reasoning behind original
CryptedUrlWebRequestCodingStrategy and WebRequestCodingStrategy. Is the
resource behaviour simply a bug? Or is it there for some reason that is
going to bite me down the road if I use my own 'fix'?
Best regards,
Sergey
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
take your photos everywhere you go - https://www.memolio.com
follow us on Twitter - http://twitter.com/Memolio
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
AW: CryptedUrlWebRequestCodingStrategy + WebRequestCodingStrategy = resource URLs are not encrypted (bug?).
You're right, i just want a consistent url look.
-Ursprüngliche Nachricht-
Von: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
Gesendet: Donnerstag, 21. Januar 2010 16:52
An: users@wicket.apache.org
Betreff: Re: CryptedUrlWebRequestCodingStrategy + WebRequestCodingStrategy =
resource URLs are not encrypted (bug?).
not sure that is possible currently. the aliasing only works on a per
class level. see SharedResources.putClassAlias().
you can add an rfe to have it enhanced.
seems like a quiet arbitrary requirement, especially when it comes to
security. an fqn does not give anything away security-wise.
-igor
On Thu, Jan 21, 2010 at 1:18 AM, Antoine van Wel
antoine.van@gmail.com wrote:
What can you do if you need to enforce that no fqn's are ever
generated in (resource) paths?
Best I can think of now is putting a breakpoint in the resourceKey
method where the fqn is retrieved, and then stepping through your full
webapp - which is a rather poor solution. Any other ideas?
Antoine
On Mon, Jan 18, 2010 at 5:18 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
the original design goal of the crypted strategy was to only encrypt
what the user sees in the url bar. since they never see resource urls
there was no reason to encrypt those.
re fqns, you can add class aliases into SharedResources to hide those.
-igor
2010/1/18 Sergejs Olefirs sergejs.olef...@parex.lv:
Hi,
I started using Wicket rather recently. As part of our security
considerations, we do not want immediately expose the underlying
framework(s) we are using, so we went ahead with URL encryption. We used
standard approach as described in examples:
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor(){
protected IRequestCodingStrategy newRequestCodingStrategy(){
return new CryptedUrlWebRequestCodingStrategy(new
WebRequestCodingStrategy());
}
};
}
Unfortunately I later discovered that this approach doesn't encrypt resource
URLs, e.g. from:
CSSPackageResource.getHeaderContribution(..);
or
link.add(new Image(logoImage));
What's worse such resource references include FQN of related classes.
After some investigation I found out that the problem is that
CryptedUrlWebRequestCodingStrategy only encrypts arguments string of the URL
and WebRequestCodingStrategy encodes resource references as path rather than
as argument.
I was able to get around this by subclassing WebRequestCodingStrategy and
overriding methods:
addResourceParameters(..);
encode(RequestCycle requestCycle, ISharedResourceRequestTarget
requestTarget);
to use arguments rather than path as resource reference.
However I'm unsure as to original reasoning behind original
CryptedUrlWebRequestCodingStrategy and WebRequestCodingStrategy. Is the
resource behaviour simply a bug? Or is it there for some reason that is
going to bite me down the road if I use my own 'fix'?
Best regards,
Sergey
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
take your photos everywhere you go - https://www.memolio.com
follow us on Twitter - http://twitter.com/Memolio
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
AW: CryptedUrlWebRequestCodingStrategy + WebRequestCodingStrategy = resource URLs are not encrypted (bug?).
Ups, sorry. The post was not for me.
-Ursprüngliche Nachricht-
Von: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
Gesendet: Donnerstag, 21. Januar 2010 16:52
An: users@wicket.apache.org
Betreff: Re: CryptedUrlWebRequestCodingStrategy + WebRequestCodingStrategy =
resource URLs are not encrypted (bug?).
not sure that is possible currently. the aliasing only works on a per
class level. see SharedResources.putClassAlias().
you can add an rfe to have it enhanced.
seems like a quiet arbitrary requirement, especially when it comes to
security. an fqn does not give anything away security-wise.
-igor
On Thu, Jan 21, 2010 at 1:18 AM, Antoine van Wel
antoine.van@gmail.com wrote:
What can you do if you need to enforce that no fqn's are ever
generated in (resource) paths?
Best I can think of now is putting a breakpoint in the resourceKey
method where the fqn is retrieved, and then stepping through your full
webapp - which is a rather poor solution. Any other ideas?
Antoine
On Mon, Jan 18, 2010 at 5:18 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
the original design goal of the crypted strategy was to only encrypt
what the user sees in the url bar. since they never see resource urls
there was no reason to encrypt those.
re fqns, you can add class aliases into SharedResources to hide those.
-igor
2010/1/18 Sergejs Olefirs sergejs.olef...@parex.lv:
Hi,
I started using Wicket rather recently. As part of our security
considerations, we do not want immediately expose the underlying
framework(s) we are using, so we went ahead with URL encryption. We used
standard approach as described in examples:
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor(){
protected IRequestCodingStrategy newRequestCodingStrategy(){
return new CryptedUrlWebRequestCodingStrategy(new
WebRequestCodingStrategy());
}
};
}
Unfortunately I later discovered that this approach doesn't encrypt resource
URLs, e.g. from:
CSSPackageResource.getHeaderContribution(..);
or
link.add(new Image(logoImage));
What's worse such resource references include FQN of related classes.
After some investigation I found out that the problem is that
CryptedUrlWebRequestCodingStrategy only encrypts arguments string of the URL
and WebRequestCodingStrategy encodes resource references as path rather than
as argument.
I was able to get around this by subclassing WebRequestCodingStrategy and
overriding methods:
addResourceParameters(..);
encode(RequestCycle requestCycle, ISharedResourceRequestTarget
requestTarget);
to use arguments rather than path as resource reference.
However I'm unsure as to original reasoning behind original
CryptedUrlWebRequestCodingStrategy and WebRequestCodingStrategy. Is the
resource behaviour simply a bug? Or is it there for some reason that is
going to bite me down the road if I use my own 'fix'?
Best regards,
Sergey
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
take your photos everywhere you go - https://www.memolio.com
follow us on Twitter - http://twitter.com/Memolio
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: CryptedUrlWebRequestCodingStrategy + WebRequestCodingStrategy = resource URLs are not encrypted (bug?).
What can you do if you need to enforce that no fqn's are ever
generated in (resource) paths?
Best I can think of now is putting a breakpoint in the resourceKey
method where the fqn is retrieved, and then stepping through your full
webapp - which is a rather poor solution. Any other ideas?
Antoine
On Mon, Jan 18, 2010 at 5:18 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
the original design goal of the crypted strategy was to only encrypt
what the user sees in the url bar. since they never see resource urls
there was no reason to encrypt those.
re fqns, you can add class aliases into SharedResources to hide those.
-igor
2010/1/18 Sergejs Olefirs sergejs.olef...@parex.lv:
Hi,
I started using Wicket rather recently. As part of our security
considerations, we do not want immediately expose the underlying
framework(s) we are using, so we went ahead with URL encryption. We used
standard approach as described in examples:
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor(){
protected IRequestCodingStrategy newRequestCodingStrategy(){
return new CryptedUrlWebRequestCodingStrategy(new
WebRequestCodingStrategy());
}
};
}
Unfortunately I later discovered that this approach doesn't encrypt resource
URLs, e.g. from:
CSSPackageResource.getHeaderContribution(..);
or
link.add(new Image(logoImage));
What's worse such resource references include FQN of related classes.
After some investigation I found out that the problem is that
CryptedUrlWebRequestCodingStrategy only encrypts arguments string of the URL
and WebRequestCodingStrategy encodes resource references as path rather than
as argument.
I was able to get around this by subclassing WebRequestCodingStrategy and
overriding methods:
addResourceParameters(..);
encode(RequestCycle requestCycle, ISharedResourceRequestTarget
requestTarget);
to use arguments rather than path as resource reference.
However I'm unsure as to original reasoning behind original
CryptedUrlWebRequestCodingStrategy and WebRequestCodingStrategy. Is the
resource behaviour simply a bug? Or is it there for some reason that is
going to bite me down the road if I use my own 'fix'?
Best regards,
Sergey
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
take your photos everywhere you go - https://www.memolio.com
follow us on Twitter - http://twitter.com/Memolio
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: CryptedUrlWebRequestCodingStrategy + WebRequestCodingStrategy = resource URLs are not encrypted (bug?).
not sure that is possible currently. the aliasing only works on a per
class level. see SharedResources.putClassAlias().
you can add an rfe to have it enhanced.
seems like a quiet arbitrary requirement, especially when it comes to
security. an fqn does not give anything away security-wise.
-igor
On Thu, Jan 21, 2010 at 1:18 AM, Antoine van Wel
antoine.van@gmail.com wrote:
What can you do if you need to enforce that no fqn's are ever
generated in (resource) paths?
Best I can think of now is putting a breakpoint in the resourceKey
method where the fqn is retrieved, and then stepping through your full
webapp - which is a rather poor solution. Any other ideas?
Antoine
On Mon, Jan 18, 2010 at 5:18 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
the original design goal of the crypted strategy was to only encrypt
what the user sees in the url bar. since they never see resource urls
there was no reason to encrypt those.
re fqns, you can add class aliases into SharedResources to hide those.
-igor
2010/1/18 Sergejs Olefirs sergejs.olef...@parex.lv:
Hi,
I started using Wicket rather recently. As part of our security
considerations, we do not want immediately expose the underlying
framework(s) we are using, so we went ahead with URL encryption. We used
standard approach as described in examples:
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor(){
protected IRequestCodingStrategy newRequestCodingStrategy(){
return new CryptedUrlWebRequestCodingStrategy(new
WebRequestCodingStrategy());
}
};
}
Unfortunately I later discovered that this approach doesn't encrypt resource
URLs, e.g. from:
CSSPackageResource.getHeaderContribution(..);
or
link.add(new Image(logoImage));
What's worse such resource references include FQN of related classes.
After some investigation I found out that the problem is that
CryptedUrlWebRequestCodingStrategy only encrypts arguments string of the URL
and WebRequestCodingStrategy encodes resource references as path rather than
as argument.
I was able to get around this by subclassing WebRequestCodingStrategy and
overriding methods:
addResourceParameters(..);
encode(RequestCycle requestCycle, ISharedResourceRequestTarget
requestTarget);
to use arguments rather than path as resource reference.
However I'm unsure as to original reasoning behind original
CryptedUrlWebRequestCodingStrategy and WebRequestCodingStrategy. Is the
resource behaviour simply a bug? Or is it there for some reason that is
going to bite me down the road if I use my own 'fix'?
Best regards,
Sergey
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
take your photos everywhere you go - https://www.memolio.com
follow us on Twitter - http://twitter.com/Memolio
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
CryptedUrlWebRequestCodingStrategy + WebRequestCodingStrategy = resource URLs are not encrypted (bug?).
Hi,
I started using Wicket rather recently. As part of our security
considerations, we do not want immediately expose the underlying
framework(s) we are using, so we went ahead with URL encryption. We used
standard approach as described in examples:
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor(){
protected IRequestCodingStrategy newRequestCodingStrategy(){
return new CryptedUrlWebRequestCodingStrategy(new
WebRequestCodingStrategy());
}
};
}
Unfortunately I later discovered that this approach doesn't encrypt resource
URLs, e.g. from:
CSSPackageResource.getHeaderContribution(..);
or
link.add(new Image(logoImage));
What's worse such resource references include FQN of related classes.
After some investigation I found out that the problem is that
CryptedUrlWebRequestCodingStrategy only encrypts arguments string of the URL
and WebRequestCodingStrategy encodes resource references as path rather than
as argument.
I was able to get around this by subclassing WebRequestCodingStrategy and
overriding methods:
addResourceParameters(..);
encode(RequestCycle requestCycle, ISharedResourceRequestTarget
requestTarget);
to use arguments rather than path as resource reference.
However I'm unsure as to original reasoning behind original
CryptedUrlWebRequestCodingStrategy and WebRequestCodingStrategy. Is the
resource behaviour simply a bug? Or is it there for some reason that is
going to bite me down the road if I use my own 'fix'?
Best regards,
Sergey
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: CryptedUrlWebRequestCodingStrategy + WebRequestCodingStrategy = resource URLs are not encrypted (bug?).
the original design goal of the crypted strategy was to only encrypt
what the user sees in the url bar. since they never see resource urls
there was no reason to encrypt those.
re fqns, you can add class aliases into SharedResources to hide those.
-igor
2010/1/18 Sergejs Olefirs sergejs.olef...@parex.lv:
Hi,
I started using Wicket rather recently. As part of our security
considerations, we do not want immediately expose the underlying
framework(s) we are using, so we went ahead with URL encryption. We used
standard approach as described in examples:
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor(){
protected IRequestCodingStrategy newRequestCodingStrategy(){
return new CryptedUrlWebRequestCodingStrategy(new
WebRequestCodingStrategy());
}
};
}
Unfortunately I later discovered that this approach doesn't encrypt resource
URLs, e.g. from:
CSSPackageResource.getHeaderContribution(..);
or
link.add(new Image(logoImage));
What's worse such resource references include FQN of related classes.
After some investigation I found out that the problem is that
CryptedUrlWebRequestCodingStrategy only encrypts arguments string of the URL
and WebRequestCodingStrategy encodes resource references as path rather than
as argument.
I was able to get around this by subclassing WebRequestCodingStrategy and
overriding methods:
addResourceParameters(..);
encode(RequestCycle requestCycle, ISharedResourceRequestTarget
requestTarget);
to use arguments rather than path as resource reference.
However I'm unsure as to original reasoning behind original
CryptedUrlWebRequestCodingStrategy and WebRequestCodingStrategy. Is the
resource behaviour simply a bug? Or is it there for some reason that is
going to bite me down the road if I use my own 'fix'?
Best regards,
Sergey
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
