Re: How to encrypt/obfuscate resource reference?

2010-03-02 Thread Sergey Olefir

As I briefly mentioned before, class aliases are, IMO, a terribly unreliable
thing to maintain. Every time someone comes up with new component that uses
resource reference they must not forget to go and register the alias for it. 

I'm predicting a 100% probability that soon enough someone will forget it
and it'll go into production -- thus defeating the entire purpose behind the
encryption/obfuscation :)

And to comment on what Antoine is saying -- I'm not entirely sure what did
you mean, but if I tried to implement encryption at
CryptedUrlWebRequestCodingStrategy, I will have to ensure that encrypted URL
will have format that will be fully parseable after browser appends relative
CSS URL to it. This is manageable by, say, encrypting only the section of
the path containing the class name. But then I'm completely unsure as to how
properly decode it / fake request for Wicket. The existing code only 'fakes'
parameters string -- but there are API methods that deal with request path
as well, and if those are not correct, I'm not sure what issues that may
cause.

Bottom line -- it must be possible to do encryption at
CryptedUrlWebRequestCodingStrategy, but it will take some serious digging to
make sure all parts fit correctly. It would be far easier to e.g.
automatically add alias in SharedResources method that deals with assigning
the name to shared resource -- the only thing it'll require is to modify
Application class so that e.g. getSharedResources() is not final.

But I'm still hoping for some 'easy' solution that doesn't entail modifying
Wicket source code to avoid headaches when upgrading.



bgooren wrote:
 
 The easiest way around this is to specify 
 http://wicket.apache.org/docs/1.4/org/apache/wicket/SharedResources.html#putClassAlias(java.lang.Class,
 java.lang.String) class aliases .
 
 The upside is that you control the generated URL, the downside is that you
 have to make sure the alias is unique.
 

-- 
View this message in context: 
http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754197.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to encrypt/obfuscate resource reference?

2010-03-02 Thread bgooren

Sorry, I overlooked that part of your original post.

I've been toying with the same idea, since class aliases are bound to cause
problems as projects grow bigger. As long as the aliases are user-generated,
they might not be unique.

So I had a quick look at the source code of WebRequestCodingStrategy, and I
think it should be possible to create a solution for your problem quite
easily:

1) subclass WebRequestCodingStrategy, and use it by overriding
newRequestCycleProcessor() in your application, and return a subclasses
WebRequestCycleProcessor which returns your custom WebRequestCodingStrategy
in the call to newRequestCodingStrategy(). Quickest solution is to create an
anonymous inner class for the custom WebRequestCycleProcessor
2) override the 
http://wicket.apache.org/docs/1.4/org/apache/wicket/protocol/http/request/WebRequestCodingStrategy.html#encode(org.apache.wicket.RequestCycle,
org.apache.wicket.request.target.resource.ISharedResourceRequestTarget)
encode  method which deals with shared resources, and implement encryption
(or simply an obfuscated, stable alias for classes)
3) override 
http://wicket.apache.org/docs/1.4/org/apache/wicket/protocol/http/request/WebRequestCodingStrategy.html#addResourceParameters(org.apache.wicket.Request,
org.apache.wicket.request.RequestParameters) addResourceParameters()  and
implement decryption



Sergey Olefir wrote:
 
 As I briefly mentioned before, class aliases are, IMO, a terribly
 unreliable thing to maintain. Every time someone comes up with new
 component that uses resource reference they must not forget to go and
 register the alias for it. 
 
 I'm predicting a 100% probability that soon enough someone will forget it
 and it'll go into production -- thus defeating the entire purpose behind
 the encryption/obfuscation :)
 
 And to comment on what Antoine is saying -- I'm not entirely sure what did
 you mean, but if I tried to implement encryption at
 CryptedUrlWebRequestCodingStrategy, I will have to ensure that encrypted
 URL will have format that will be fully parseable after browser appends
 relative CSS URL to it. This is manageable by, say, encrypting only the
 section of the path containing the class name. But then I'm completely
 unsure as to how properly decode it / fake request for Wicket. The
 existing code only 'fakes' parameters string -- but there are API methods
 that deal with request path as well, and if those are not correct, I'm not
 sure what issues that may cause.
 
 Bottom line -- it must be possible to do encryption at
 CryptedUrlWebRequestCodingStrategy, but it will take some serious digging
 to make sure all parts fit correctly. It would be far easier to e.g.
 automatically add alias in SharedResources method that deals with
 assigning the name to shared resource -- the only thing it'll require is
 to modify Application class so that e.g. getSharedResources() is not
 final.
 
 But I'm still hoping for some 'easy' solution that doesn't entail
 modifying Wicket source code to avoid headaches when upgrading.
 
 
 
 bgooren wrote:
 
 The easiest way around this is to specify 
 http://wicket.apache.org/docs/1.4/org/apache/wicket/SharedResources.html#putClassAlias(java.lang.Class,
 java.lang.String) class aliases .
 
 The upside is that you control the generated URL, the downside is that
 you have to make sure the alias is unique.
 
 
 

-- 
View this message in context: 
http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754615.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to encrypt/obfuscate resource reference?

2010-03-02 Thread bgooren

Ok, scratch that comment too...

I see Antoine dug up an old thread of yours where you already found out
about the possibility to override WebRequestCodingStrategy.

I also see that Antoine created WICKET-2731 and that it has been closed as
resolved/fixed, so there should be some hooks available in wicket 1.4.7
(which is to be release shortly according to the dev mailing list).


Sergey Olefir wrote:
 
 As I briefly mentioned before, class aliases are, IMO, a terribly
 unreliable thing to maintain. Every time someone comes up with new
 component that uses resource reference they must not forget to go and
 register the alias for it. 
 
 I'm predicting a 100% probability that soon enough someone will forget it
 and it'll go into production -- thus defeating the entire purpose behind
 the encryption/obfuscation :)
 
 And to comment on what Antoine is saying -- I'm not entirely sure what did
 you mean, but if I tried to implement encryption at
 CryptedUrlWebRequestCodingStrategy, I will have to ensure that encrypted
 URL will have format that will be fully parseable after browser appends
 relative CSS URL to it. This is manageable by, say, encrypting only the
 section of the path containing the class name. But then I'm completely
 unsure as to how properly decode it / fake request for Wicket. The
 existing code only 'fakes' parameters string -- but there are API methods
 that deal with request path as well, and if those are not correct, I'm not
 sure what issues that may cause.
 
 Bottom line -- it must be possible to do encryption at
 CryptedUrlWebRequestCodingStrategy, but it will take some serious digging
 to make sure all parts fit correctly. It would be far easier to e.g.
 automatically add alias in SharedResources method that deals with
 assigning the name to shared resource -- the only thing it'll require is
 to modify Application class so that e.g. getSharedResources() is not
 final.
 
 But I'm still hoping for some 'easy' solution that doesn't entail
 modifying Wicket source code to avoid headaches when upgrading.
 
 
 
 bgooren wrote:
 
 The easiest way around this is to specify 
 http://wicket.apache.org/docs/1.4/org/apache/wicket/SharedResources.html#putClassAlias(java.lang.Class,
 java.lang.String) class aliases .
 
 The upside is that you control the generated URL, the downside is that
 you have to make sure the alias is unique.
 
 
 

-- 
View this message in context: 
http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754749.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to encrypt/obfuscate resource reference?

2010-03-02 Thread Sergey Olefir


Thing is, I already toyed with WebRequestCodingStrategy -- specifically I
changed how resources are encoded by replacing URL path with URL parameter.
And I broke CSS/relative references in the process as I found out much later
:) (as you found out already in your another post ;))

Although if I do something less drastic -- such as simply encoding the
section with FQN -- I might break less stuff... Ah well, as you pointed out
(and special thanks for that :)), 1.4.7 hopefully will be out soon with the
some fix for the issue, maybe I can just wait it out.


bgooren wrote:
 
 So I had a quick look at the source code of WebRequestCodingStrategy, and
 I think it should be possible to create a solution for your problem quite
 easily:
 

-- 
View this message in context: 
http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754796.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to encrypt/obfuscate resource reference?

2010-03-02 Thread Antoine van Wel
A flag has been introduced that when set will throw an error when an
fqn would be used. It will be in 1.4.7, which is currently in the
voting phase, so it will be available within a week.

But this would mean you'd have to alias all the classes anyway.


Antoine


On Tue, Mar 2, 2010 at 12:33 PM, Sergey Olefir solf.li...@gmail.com wrote:


 Thing is, I already toyed with WebRequestCodingStrategy -- specifically I
 changed how resources are encoded by replacing URL path with URL parameter.
 And I broke CSS/relative references in the process as I found out much later
 :) (as you found out already in your another post ;))

 Although if I do something less drastic -- such as simply encoding the
 section with FQN -- I might break less stuff... Ah well, as you pointed out
 (and special thanks for that :)), 1.4.7 hopefully will be out soon with the
 some fix for the issue, maybe I can just wait it out.


 bgooren wrote:

 So I had a quick look at the source code of WebRequestCodingStrategy, and
 I think it should be possible to create a solution for your problem quite
 easily:


 --
 View this message in context: 
 http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754796.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 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: How to encrypt/obfuscate resource reference?

2010-03-02 Thread Sergey Olefir


Thanks for heads up.

I guess it's back to hacking WebRequestCodingStrategy for me, the flag is
better than nothing, but I'm not eager in having application crash in
production because someone forgot to map something and somehow it slipped
past testing.


Antoine van Wel wrote:
 
 A flag has been introduced that when set will throw an error when an
 fqn would be used. It will be in 1.4.7, which is currently in the
 voting phase, so it will be available within a week.
 
 But this would mean you'd have to alias all the classes anyway.
 

-- 
View this message in context: 
http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754862.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to encrypt/obfuscate resource reference?

2010-03-02 Thread Martijn Dashorst
Create a unit test case that scans your application for resources and
checks if the class is set. If not, fail. If set, check if it is
unique, if not fail.

Martijn

On Tue, Mar 2, 2010 at 12:40 PM, Sergey Olefir solf.li...@gmail.com wrote:


 Thanks for heads up.

 I guess it's back to hacking WebRequestCodingStrategy for me, the flag is
 better than nothing, but I'm not eager in having application crash in
 production because someone forgot to map something and somehow it slipped
 past testing.


 Antoine van Wel wrote:

 A flag has been introduced that when set will throw an error when an
 fqn would be used. It will be in 1.4.7, which is currently in the
 voting phase, so it will be available within a week.

 But this would mean you'd have to alias all the classes anyway.


 --
 View this message in context: 
 http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754862.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org





-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to encrypt/obfuscate resource reference?

2010-03-02 Thread Sergey Olefir


Err, I guess I don't quite understand what you're proposing... My
understanding is that I need to know all class names that are used by
application as part of ResourceReference (and possibly something else too).
How would I scan for that?


Martijn Dashorst wrote:
 
 Create a unit test case that scans your application for resources and
 checks if the class is set. If not, fail. If set, check if it is
 unique, if not fail.
 
 Martijn
 

-- 
View this message in context: 
http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754984.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to encrypt/obfuscate resource reference?

2010-03-02 Thread Martijn Dashorst
Take a look at the spring component scanner for an implementation of
how to search the class path. Then it is just a series of
ResourceReference.class.isAssignableFrom(clz) queries and applying
your specific logic.

For example we use the following code to scan for specific patterns in
html files (such as style= attributes in html code, which we consider
illegal—use classes and stylesheets instead).

ResourcePatternResolver, PathMatchingResourcePatternResolver are
classes that comes from Spring.

ResourcePatternResolver resourcePatternResolver = new
PathMatchingResourcePatternResolver();
for (String packageName : getPackageNames())
{
String usePackageName = packageName;
if (!usePackageName.endsWith(.))
usePackageName += .;
String filePatter =
ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX
+ ClassUtils.convertClassNameToResourcePath(usePackageName)
+ **/*.html;
try
{
Resource[] resources = resourcePatternResolver.getResources(filePatter);
for (Resource resource : resources)
{
if (resource.isReadable())
{
ListString matches =
getMatches(resource.getInputStream(), pattern);
String fileName = resource.getURI().getPath();
if (errorWhenFound)
{
if (!matches.isEmpty())
addError(fileName + :  + matches);
}
else
{
if (matches.isEmpty())
addError(fileName);
}
}
}
}
catch (IOException e)
{
addError(e.getMessage());
}
}
assertNoErrors(message);

Martijn

On Tue, Mar 2, 2010 at 12:56 PM, Sergey Olefir solf.li...@gmail.com wrote:


 Err, I guess I don't quite understand what you're proposing... My
 understanding is that I need to know all class names that are used by
 application as part of ResourceReference (and possibly something else too).
 How would I scan for that?


 Martijn Dashorst wrote:

 Create a unit test case that scans your application for resources and
 checks if the class is set. If not, fail. If set, check if it is
 unique, if not fail.

 Martijn


 --
 View this message in context: 
 http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754984.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org





-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to encrypt/obfuscate resource reference?

2010-03-02 Thread Sergey Olefir


I admit I didn't research in-depth what you've suggested, but from the
quoted piece it seems that your suggestion will find all subclasses of
ResourceReference. But to actually test that all resources are properly
mapped, it would be necessary to locate all invocations of the
ResourceReference constructors and scan their parameters. I have hard time
imagining how it could possibly work without resorting to AspectJ (or AOP in
general).

Also the same problem may be relevant for e.g. Image() and possibly other
stuff.

Basically, unless I completely misunderstand what you're suggesting, I don't
really see how such scanning might work.


Martijn Dashorst wrote:
 
 Take a look at the spring component scanner for an implementation of
 how to search the class path. Then it is just a series of
 ResourceReference.class.isAssignableFrom(clz) queries and applying
 your specific logic.
 

-- 
View this message in context: 
http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27756016.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to encrypt/obfuscate resource reference?

2010-03-02 Thread James Carman
You might also look into the scannotation project.

On Tue, Mar 2, 2010 at 8:33 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 Take a look at the spring component scanner for an implementation of
 how to search the class path. Then it is just a series of
 ResourceReference.class.isAssignableFrom(clz) queries and applying
 your specific logic.

 For example we use the following code to scan for specific patterns in
 html files (such as style= attributes in html code, which we consider
 illegal—use classes and stylesheets instead).

 ResourcePatternResolver, PathMatchingResourcePatternResolver are
 classes that comes from Spring.

 ResourcePatternResolver resourcePatternResolver = new
 PathMatchingResourcePatternResolver();
 for (String packageName : getPackageNames())
 {
    String usePackageName = packageName;
    if (!usePackageName.endsWith(.))
        usePackageName += .;
    String filePatter =
        ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX
            + ClassUtils.convertClassNameToResourcePath(usePackageName)
 + **/*.html;
    try
    {
        Resource[] resources = 
 resourcePatternResolver.getResources(filePatter);
        for (Resource resource : resources)
        {
            if (resource.isReadable())
            {
                ListString matches =
 getMatches(resource.getInputStream(), pattern);
                String fileName = resource.getURI().getPath();
                if (errorWhenFound)
                {
                    if (!matches.isEmpty())
                        addError(fileName + :  + matches);
                }
                else
                {
                    if (matches.isEmpty())
                        addError(fileName);
                }
            }
        }
    }
    catch (IOException e)
    {
        addError(e.getMessage());
    }
 }
 assertNoErrors(message);

 Martijn

 On Tue, Mar 2, 2010 at 12:56 PM, Sergey Olefir solf.li...@gmail.com wrote:


 Err, I guess I don't quite understand what you're proposing... My
 understanding is that I need to know all class names that are used by
 application as part of ResourceReference (and possibly something else too).
 How would I scan for that?


 Martijn Dashorst wrote:

 Create a unit test case that scans your application for resources and
 checks if the class is set. If not, fail. If set, check if it is
 unique, if not fail.

 Martijn


 --
 View this message in context: 
 http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27754984.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org





 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.4 increases type safety for web applications
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4

 -
 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: How to encrypt/obfuscate resource reference?

2010-03-02 Thread Sergey Olefir
,
ISharedResourceRequestTarget requestTarget)
{
final String sharedResourceKey = requestTarget.getResourceKey();
if ((sharedResourceKey == null) ||
(sharedResourceKey.trim().length() == 0))
{
return ;
}
else
{
final AppendingStringBuffer buffer = new AppendingStringBuffer(
sharedResourceKey.length() * 3); // Guesstimate as to how
big encrypted string will be
buffer.append(RESOURCES_PATH_PREFIX);

// Split resource key and determine whether we need to encrypt
it (whether it has FQN).
String head;
String tail;
int slash = sharedResourceKey.indexOf('/');
if (slash  0)
{
head = sharedResourceKey;
tail = ;
}
else if (slash == 0)
{
head = ;
tail = sharedResourceKey;
}
else
{
head = sharedResourceKey.substring(0, slash);
tail = sharedResourceKey.substring(slash);
}

// Check if head looks like FQN.
if (head.indexOf('.') = 0)
{
// Think it's FQN...
buffer.append(ENCRYPTED_FQN_PREFIX);
buffer.append(encrypt(head));
}
else
{
// Non-FQN
buffer.append(head);
}

// Write out the tail.
buffer.append(tail);

Map map = requestTarget.getRequestParameters().getParameters();
if (map != null  map.size()  0)
{
buffer.append('?');
IteratorEntryString, String[] it =
map.entrySet().iterator();
while (it.hasNext())
{
Map.EntryString, String[] entry = it.next();
buffer.append(entry.getKey());
buffer.append('=');
buffer.append(entry.getValue());
if (it.hasNext())
{
buffer.append('');
}
}
}
return buffer;
}
}

/**
 * Encrypts string.
 */
public static String encrypt(String str)
{
String encrypted = toEncryptedMap.get(str);
if (encrypted != null)
return encrypted;

encrypted = encryptor.encrypt(str);
toEncryptedMap.put(str, encrypted);
toUnencryptedMap.put(encrypted, str);

return encrypted;
}


/**
 * Decrypts string.
 */
public static String decrypt(String encrypted)
{
String str = toUnencryptedMap.get(encrypted);
if (str != null)
return str;

str = encryptor.decrypt(encrypted);
toEncryptedMap.put(str, encrypted);
toUnencryptedMap.put(encrypted, str);

return str;
}

}

-- 
View this message in context: 
http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27757761.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to encrypt/obfuscate resource reference?

2010-03-02 Thread bgooren

Good to know I contributed something useful to this thread haha.

The code looks like the stuff I had in mind.

You gotta love Wicket for making it quite easy to do this stuff; Although
the URL encoding/decoding can be quite complex for beginners, but that is
likely to be fixed in the future (I've had a look at Matej's wicket-ng
implementation, and it looks very promising).


Sergey Olefir wrote:
 
 
 Thanks to your idea, I played around with WebRequestCodingStrategy and
 below is what I came up with.
 
 It uses jasypt, but feel free to replace it with whatever you like more.
 

-- 
View this message in context: 
http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27757852.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



How to encrypt/obfuscate resource reference?

2010-03-01 Thread Sergey Olefir
Hi,

out of the box Wicket generates urls for packaged resources that
contain fully-qualified class names, e.g.:
link rel=stylesheet type=text/css
href=resources/org.example.MyClassName/decorations/style.css /

Now in accordance with our security policies we are not allowed to
expose internal application details -- and fully qualified class name
certainly fits that category.

On the other hand we do very much want to package resources together
with the components that use them -- this approach seems to be way
more convenient in practice than any other option.

So I've been looking into whether it is possible to encrypt resource
references (at least the class name part). My research led me to
SharedResources.resourceKey(final Class? scope, final String path,
final Locale locale, final String style)
method which apparently is responsible for inserting FQNs into urls.

Unfortunately this place seems to be locked down hard -- method is
'NOT PART OF THE WICKET PUBLIC API' and corresponding accessor method
in Application is final. Moreover the field containing the instance in
Application is private final -- so even reflection is no help.

So any ideas how can I encrypt/obfuscate resource references without
resorting to aliasing every single class on the classloader path?
(aliasing 'as needed' is not really an option as it would be
devilishly hard to ensure that there are no un-aliased urls as the
system is developed in the future and new components/resources are
added)

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to encrypt/obfuscate resource reference?

2010-03-01 Thread Antoine van Wel
for a discussion and suggestion see

http://old.nabble.com/CryptedUrlWebRequestCodingStrategy-%2B-WebRequestCodingStrategy-%3D-resource-URLs-are-not-encrypted-(bug-).-td27209560.html

quote 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. 


haven't tried that myself yet, but will need it in the near future.


IMHO it would make sense to include this in the
CryptedUrlWebRequestCodingStrategy.


regards
Antoine.





On Mon, Mar 1, 2010 at 4:01 PM, Sergey Olefir solf.li...@gmail.com wrote:
 Hi,

 out of the box Wicket generates urls for packaged resources that
 contain fully-qualified class names, e.g.:
 link rel=stylesheet type=text/css
 href=resources/org.example.MyClassName/decorations/style.css /

 Now in accordance with our security policies we are not allowed to
 expose internal application details -- and fully qualified class name
 certainly fits that category.

 On the other hand we do very much want to package resources together
 with the components that use them -- this approach seems to be way
 more convenient in practice than any other option.

 So I've been looking into whether it is possible to encrypt resource
 references (at least the class name part). My research led me to
 SharedResources.resourceKey(final Class? scope, final String path,
 final Locale locale, final String style)
 method which apparently is responsible for inserting FQNs into urls.

 Unfortunately this place seems to be locked down hard -- method is
 'NOT PART OF THE WICKET PUBLIC API' and corresponding accessor method
 in Application is final. Moreover the field containing the instance in
 Application is private final -- so even reflection is no help.

 So any ideas how can I encrypt/obfuscate resource references without
 resorting to aliasing every single class on the classloader path?
 (aliasing 'as needed' is not really an option as it would be
 devilishly hard to ensure that there are no un-aliased urls as the
 system is developed in the future and new components/resources are
 added)

 -
 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: How to encrypt/obfuscate resource reference?

2010-03-01 Thread Sergey Olefir

He he, that was my old thread there :)

Thing is, I just recently discovered, that encoding resources as arguments
(rather than paths) completely breaks relative URLs discussed there:
http://old.nabble.com/How-to-'resolve'-URL-in-stylesheet--td27720293.html
(for the simple reason that browser strips out arguments when resolving
relative url).

So it is necessary to come up with some other solution.



Antoine van Wel wrote:
 
 for a discussion and suggestion see
 
 http://old.nabble.com/CryptedUrlWebRequestCodingStrategy-%2B-WebRequestCodingStrategy-%3D-resource-URLs-are-not-encrypted-(bug-).-td27209560.html
 

-- 
View this message in context: 
http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27745911.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: How to encrypt/obfuscate resource reference?

2010-03-01 Thread Antoine van Wel
Oops :-)

can't you just take the path and encrypt that using the same strategy
as the cryptedurl.. thingy is using?


Antoine


On Mon, Mar 1, 2010 at 5:43 PM, Sergey Olefir solf.li...@gmail.com wrote:

 He he, that was my old thread there :)

 Thing is, I just recently discovered, that encoding resources as arguments
 (rather than paths) completely breaks relative URLs discussed there:
 http://old.nabble.com/How-to-'resolve'-URL-in-stylesheet--td27720293.html
 (for the simple reason that browser strips out arguments when resolving
 relative url).

 So it is necessary to come up with some other solution.



 Antoine van Wel wrote:

 for a discussion and suggestion see

 http://old.nabble.com/CryptedUrlWebRequestCodingStrategy-%2B-WebRequestCodingStrategy-%3D-resource-URLs-are-not-encrypted-(bug-).-td27209560.html


 --
 View this message in context: 
 http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27745911.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 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: How to encrypt/obfuscate resource reference?

2010-03-01 Thread bgooren

The easiest way around this is to specify 
http://wicket.apache.org/docs/1.4/org/apache/wicket/SharedResources.html#putClassAlias(java.lang.Class,
java.lang.String) class aliases .

The upside is that you control the generated URL, the downside is that you
have to make sure the alias is unique.
 

Sergey Olefir wrote:
 
 Hi,
 
 out of the box Wicket generates urls for packaged resources that
 contain fully-qualified class names, e.g.:
 link rel=stylesheet type=text/css
 href=resources/org.example.MyClassName/decorations/style.css /
 
 Now in accordance with our security policies we are not allowed to
 expose internal application details -- and fully qualified class name
 certainly fits that category.

-- 
View this message in context: 
http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27748507.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org