Re: What happens after browser's 'back' button?
Any suggestions as to where I should start looking (source code or otherwise) to understand how Wicket actually handles back button? -- View this message in context: http://old.nabble.com/What-happens-after-browser%27s-%27back%27-button--tp28149886p28179655.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: What happens after browser's 'back' button?
Hi,
thanks for the reply and the suggestion.
However I'm not sure it'll work (or else I'm misunderstanding what you're
suggesting). As you said yourself, 'when the user hits back wicket will pull
the old page instance from the pagemap and rerender it'. In my limited
testing it seemed that when handling 'back' button Wicket would restore both
model state *and* page instance variables state to whatever it was when that
page was actually rendered. This means that any flag set after that page
(e.g. when handling the first post) will be null and void. Thus nothing will
prevent user from re-submitting that page again.
To be fair, I only tested without that header you're suggesting -- but I'm
unsure as to what that header would change, it should be roughly equivalent
to hitting F5 on the old page and it doesn't seem to change anything in how
Wicket handles back button.
Now on that tangent I really would love to know what kind of thingamajig
Wicket does to restore both model and instance variable state -- only
serialization comes to mind to be honest... Is it what really is happening?
Another thing is that I would love to avoid sticking 'double submit
prevention' code into each and every form. Considering the stuff Wicket
already does with back button support I assume there ought to be a
centralized place to detect that user has, in fact, used the back button, so
at least some form of generalized 'back button prevention' ought to be
possible. I'm just totally unsure as to where to look.
McIlwee, Craig wrote:
>
> As long as you prevent the browser from caching the page with the form
> (just the page itself, caching the resources is fine) then when the user
> hits back wicket will pull the old page instance from the pagemap and
> rerender it. That page instance is the same one that was used the first
> time, so its state will still be the same. Just set some flag when the
> user submits, and also check that flag when processing the form like this:
>
> onSubmit(...) {
> if (!submitted) {
> submitted = true;
> // do some stuff
> } else {
> // redirect to another page
> }
> }
>
> Wicket does set some cache headers, but to disable it in FF we had to set
> 1 extra header. If you check the setHeaders method in WebPage you'll see
> that they set 3 headers I think and then there is one other header (must
> revalidate?) that they have commented out. That commented header did the
> trick for us. As for the redirect, you might be able to pull the 'last
> valid page' as you call it from the page map, not sure though.
>
> Craig
>
--
View this message in context:
http://old.nabble.com/What-happens-after-browser%27s-%27back%27-button--tp28149886p28162659.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
What happens after browser's 'back' button?
Hi, our first Wicket-based application is about to go into testing and I'm feeling rather uncomfortable about the fact that I don't really understand what happens when user uses browser's back button and then submits some 'outdated' form. Can someone elaborate please on what exactly happens when Wicket receives submit from the 'old' page? On a more specific note, I will most probably need to block user from submitting the same form more than once. E.g.: - If I wanted to prevent user from using back button at all, how would I determine that the incoming submit is from the 'old' page? - If I determined that Wicket received submit from the 'old' page, how would I send user back to the last 'valid' page they were on? - If I wanted to detect that user submits the same form twice (without necessarily blocking the back button in all cases), how would I go about it? I suppose I could store something in Session to track which forms were already submitted? P.S. Sorry for kind of 'reposting' my previous question, but I'm running out of time on this project and really would love to understand how to properly handle browser's 'back' button... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Support for back button and new windows?
Hi, thanks for the reply :) Some comments: - very hacky way is not appropriate (I think) as it'll break clustering, session persistence (server restart), etc. - less hacky: that's something I've been thinking about. But I'd need more specific information to go that way -- how to determine exactly what to expire from the page store, how to distinguish page expired vs. session expired situations, how to redirect user back to the 'last valid page' they were on (before they tried to (ab)use browser's back button)? Any particular suggestions? - even less hacky: I'm not 100% positive what exactly is that you're suggesting, but I do have a question -- could it possibly work? In my experiments with Wicket and browser's back button, Wicket seems to demonstrate a miraculous capability of restoring state as it was at the point of time when that particular page was rendered -- that's including both stuff that is in the model and also in instance variables in page instances. I really need to somehow understand how this back support works -- I'm rather scared that my lack of understanding will lead to some rather unexpected and unpleasant failures in production. Any suggestions as to where to look for info? Martijn Dashorst wrote: > > A couple of thoughts come to mind: > - very hacky: ensure the wizard pages are not serializable -> they > won't end up in the pagestore so any back button activity will result > in pageexpired messages > - less hacky: remove the wizard pages after the final submission from > the pagestore (I believe you can evict them) > - even less hacky: in onsubmit of your final step mark the form > submitted (create a field 'submitted' and set it to true) and add a > validator that fails when the flag is true > > Martijn > > On Fri, Mar 26, 2010 at 4:48 PM, Sergey Olefir > wrote: >> >> Also on this subject -- if I want to prevent users from submitting wizard >> (multi-page form) again via back button after they've submitted it once >> (or >> in other conditions), what would be the best way to approach this >> problem? >> >> And similarly -- if I want to prevent users from using back button at all >> (e.g. show them the last 'normally' generated page if they submit >> anything >> from the 'old' page), what would be the best way to achieve this? > > -- View this message in context: http://old.nabble.com/Support-for-back-button-and-new-windows--tp28028525p28080646.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: Support for back button and new windows?
Also on this subject -- if I want to prevent users from submitting wizard (multi-page form) again via back button after they've submitted it once (or in other conditions), what would be the best way to approach this problem? And similarly -- if I want to prevent users from using back button at all (e.g. show them the last 'normally' generated page if they submit anything from the 'old' page), what would be the best way to achieve this? Sergey Olefir wrote: > > Hi, > > I'm looking for a good source of information on Wicket's support for > browser's back button and also on what happens when user opens a new > tab/window. I feel this is something I need to understand well before > we can deploy our first Wicket application in production. > -- View this message in context: http://old.nabble.com/Support-for-back-button-and-new-windows--tp28028525p28043507.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
Support for back button and new windows?
Hi, I'm looking for a good source of information on Wicket's support for browser's back button and also on what happens when user opens a new tab/window. I feel this is something I need to understand well before we can deploy our first Wicket application in production. I found this: http://cwiki.apache.org/WICKET/browser-back-forward.html But this is rather old page, so I'm not sure it's still accurate. Furthermore after reading that page I'm still unsure what it all implies. For example, regarding 'back button' support, after a little experimentation it seems as if Wicket serializes/stores each page it generates -- including all the data involved. E.g. if I have multi-page wizard that stores all data in a single object, and if I fill pages 1 & 2 (and I'm currently at page 3), but then use browser's 'back' button to go to page 1 and submit that -- I'll get empty page 2 -- with all the data I've entered previously 'forgotten'. That seems to strongly imply data serialization. So what actually happens when browser's back button is used? And similarly -- what happens when user opens new tab/window in the middle of the wizard? Does user then get two completely separate wizard forms that can be changed/submitted separately? Or something else? Thanks in advance! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Simple way to use button as link?
Hi,
for user interface reasons I want to use button on an otherwise
read-only page that would simply open another page (e.g. act just like
a link would). What would be the simplest way to achieve that
(including i18n)?
I'm currently using form like this:
Placeholder:
Execute
---
Form form = new Form("signButtonForm")
{
protected void onSubmit()
{
setResponsePage(new OtherPage());
}
};
add(form);
---
This works, but seems rather verbose and roundabout. Is there a better way?
Thanks in advance!
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Analyzing HTML markup.
Hi, is it possible to (easily) analyze HTML markup at runtime? More specifically I'm thinking about implementing a component that will examine its (or more realistically the markup of extending class) markup to determine whether or not particular wicket:id is present. Or, in other words, is it possible to implement base component that will or will not add(..) some 'other component' inside itself depending on whether child (extending class) has provided place for 'other component' in its markup? Thanks in advance! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Support for serialization debugging.
Thanks for the reply, Igor. Indeed it was my own error -- there was a misconfiguration in our log4j config which led to me simply not seeing error messages generated by Wicket when serialization failed. It's only when I was shutting down the server, the error message had enough severity to be seen. On the other hand I found out a tidbit of information that I wanted to share with the community :) Under current Sun JDK, if you set JVM option: -Dsun.io.serialization.extendedDebugInfo=true then any NotSerializableExceptions will include detailed debug information showing where the problem has occurred. This might be useful in cases where SerializationChecker is not immediately available. igor.vaynberg wrote: > > seems like it should be running. > > AbstractPageStore:203 serializes the page by calling > Objects.objectToByteArray() which by default uses > DefaultObjectStreamFactory which in turn runs your object through the > SerializableChecker if an exception occurs, see > IObjectStreamFactory:125 > > so unless you installed your own objectoutputstreamfactory or if you > are running on a non-sun jdk (serializable checker hacks stuff using > reflection) you should be using it... > > -igor > -- View this message in context: http://old.nabble.com/Support-for-serialization-debugging.-tp27820726p27851166.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
Support for serialization debugging.
Hi, what is the current 'proper' way to debug serialization issues in Wicket? My web search led me to two things: - Wicket contains SerializableChecker class whose explicit purpose is to assist in tracking down serialization issues. - At some point it seems that in development mode Wicket used to serialize pages on each request (so that you'll catch your serialization issues early). However right now it seems that Wicket is using SecondLevelCacheSessionStore for serialization purposes -- and the implementation does not make use of SerializableChecker. Also current Wicket apparently does not serialize pages on each request in development mode (at least not by default). So with the current Wicket is there a way to force page serialization on each request and to enable serialization debugging via SerializableChecker or something else? I'm asking because to track down my serialization issue recently I had to basically copy-paste SecondLevelCacheSessionStore and manually add SerializableChecker invocation to track it down. Plus the error only became apparent when Tomcat was shutdown with 'proper' sessions still in memory. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: FeedbackPanel for Dynamic Form
I'm not 100% sure what exactly is your issue, but have you taken a look at subclasses of IFeedbackMessageFilter ? They allow filtering messages based on component instance, for example. You will have to use reuseItems=true in ListView though most likely. Brad Grier wrote: > > I've written a dynamic form engine which does its work using a ListView > and Fragment subclasses representing the various form fields. Everything > works great including saving and retrieving form information. Now that the > fun is over, I've run into a problem adding validation. In the markup for > the fragment subclasses, the wicket:id is always "field". That's > okay...until I try to add a FeebackPanel to the form to report validation > errors. Since the identifier for every form field is the same, the > messages displayed in the panel are useless. Any advice? > -- View this message in context: http://old.nabble.com/FeedbackPanel-for-Dynamic-Form-tp27764535p27766528.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?
bgooren wrote: > > You gotta love Wicket for making it quite easy to do this stuff; > Actually I think in this particular case Wicket didn't make it 'easy' to do what I needed to do. It would've been easy and logical if I could change SharedResources method so it doesn't use class name in the first place. The second logical option (or maybe even first) would've been CryptedUrlWebRequestCodingStrategy -- but modifications there for this purpose appear to be non-trivial. Modifications I've made to WebRequestCodingStrategy are closer to a dirty hack -- they depend on internal format used by SharedResources and are doing a guesswork as to what is FQN and what is not. But at least modifications there are possible and are minor (not likely to break something else). -- View this message in context: http://old.nabble.com/How-to-encrypt-obfuscate-resource-reference--tp27744679p27757987.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?
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:
>
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.
package crypt.wicket;
import java.util.Iterator;
import java.util.Map;
import java.util.Map.Entry;
import java.util.concurrent.ConcurrentHashMap;
import org.apache.wicket.Request;
import org.apache.wicket.RequestCycle;
import org.apache.wicket.protocol.http.request.WebRequestCodingStrategy;
import org.apache.wicket.request.RequestParameters;
import
org.apache.wicket.request.target.resource.ISharedResourceRequestTarget;
import org.apache.wicket.util.string.AppendingStringBuffer;
import org.jasypt.encryption.pbe.StandardPBEStringEncryptor;
import org.jasypt.salt.ZeroSaltGenerator;
/**
* Version of standard {...@link WebRequestCodingStrategy} that encrypts FQNs
* (full qualified names of classes) in resource references.
*
* @author Sergey Olefir
*/
public class CryptWebRequestCodingStrategy extends WebRequestCodingStrategy
{
/**
* Prefix for encrypted FQNs.
*/
public static final String ENCRYPTED_FQN_PREFIX = "---";
/**
* Map of unencrypted -> encrypted strings.
*/
protected static final Map toEncryptedMap = new
ConcurrentHashMap();
/**
* Map of encrypted -> unencrypted strings.
*/
protected static final Map toUnencryptedMap = new
ConcurrentHashMap();
/**
* Encrypted used to encrypt FQNs.
*/
private static final StandardPBEStringEncryptor encryptor;
static
{
encryptor = new StandardPBEStringEncryptor();
encryptor.setAlgorithm("PBEWithMD5AndDES");
encryptor.setSaltGenerator(new ZeroSaltGenerator()); // Need to use
zero salt so that URLs are stable.
encryptor.setStringOutputType("hexadecimal"); // To avoid slashes in
the result (base64 can produce slashes).
encryptor.setPassword("");
}
/* (non-Javadoc)
* @see
org.apache.wicket.protocol.http.request.WebRequestCodingStrategy#addResourceParameters(org.apache.wicket.Request,
org.apache.wicket.request.RequestParameters)
*/
@Override
protected void addResourceParameters(Request request,
RequestParameters parameters)
{
String pathInfo = request.getPath();
if (pathInfo != null && pathInfo.startsWith(RESOURCES_PATH_PREFIX))
{
int ix = RESOURCES_PATH_PREFIX.length();
if (pathInfo.length() > ix)
{
StringBuffer path = new
StringBuffer(pathInfo.substring(ix));
int ixSemiColon = path.indexOf(";");
// strip off any jsession id
if (ixSemiColon != -1)
{
int ixEnd = path.indexOf("?");
if (ixEnd == -1)
{
ixEnd = path.length();
}
path.delete(ixSemiColon, ixEnd);
}
// Check if we need to decrypt FQN.
String pathString = path.toString();
if (pathString.startsWith(ENCRYPTED_FQN_PREFIX))
{
if (pathString.length() > ENCRYPTED_FQN_PREFIX.length())
{
// Need to decrypt.
pathString =
pathString.substring(ENCRYPTED_FQN_PREFIX.length());
String head;
String tail;
int slash = pathString.indexOf('/');
if (slash < 0)
{
head = pathString;
tail = "";
}
else if (slash == 0)
{
head = "";
tail = pathString;
}
else
{
head = pathString.substring(0, slash);
tail = pathString.substring(slash);
}
// Do decrypt.
pathString = decrypt(head) + tail;
}
}
parameters.setResourceKey(pathString);
}
}
}
/* (non-Javadoc)
* @see
org.apache.wicket.protocol.http.request.WebRequestCodingStrategy#encode(org.apache.wicket.RequestCycle,
org.apache.wicket.request.target.resource.ISharedResourceRequestTarget)
*/
@SuppressWarnings("unchecked")
@Overrid
Re: How to encrypt/obfuscate resource reference?
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?
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?
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?
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: RE: How can i know when a users redirects to other page
I'm not sure if session invalidation will be carried out if server stops/crashes. Although I think the session invalidation mechanism is still the most reliable of all that was proposed (my personal first reaction was "you can't do it reliably" -- although after reading the thread I have to agree that e.g. session invalidation might work). Anyway, if going session invalidation route, it might be necessary to clean up the directory at the server startup to make sure all stray files are cleaned up. reiern70 wrote: > > http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpSessionListener.html > > Ernesto > -- View this message in context: http://old.nabble.com/How-can-i-know-when-a-users-redirects-to-other-page-tp27742803p27754252.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?
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 specify codebase for applet?
Thanks for the pointer, I was able to solve my problem with this information. However I had to roll my own versions of ContextImage and ContextPathGenerator -- because the ones supplied with Wicket appear to be hardcoded to use 'src' attribute. Maybe generic versions that are able to manipulate specified attribute should be included in Wicket distribution? Martijn Dashorst wrote: > > See the source for ContextImage for an example. > > Martijn > -- View this message in context: http://old.nabble.com/How-to-specify-codebase-for-applet--tp27742745p27745948.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?
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
How to encrypt/obfuscate resource reference?
Hi, out of the box Wicket generates urls for packaged resources that contain fully-qualified class names, e.g.: 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
How to specify codebase for applet?
Hi, in our application we need to make use of an applet. For the size and logistics reasons I don't want to package the required applet jars inside Java packages (that is unlike e.g. images and css that we do package together with the components). So, say, I'll package the jars under 'applet' web folder so that they are web-accessible via http://server/context-path/applet/jar1.jar etc. Now I don't want to hardcore context-path into the markup file, so I don't want to simply write in HTML: You need Java support to run this applet. What do I need to write so that codebase refers to the proper folder regardless of the chosen context-path? (folder name inside the context-path will still be the same) Thanks in advance! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to 'resolve' URL in stylesheet?
*bonks self on the head* Somehow I never realised that paths in CSS are resolved against CSS itself, not the HTML page (being a total HTML noob and all it's not that surprising). Thanks for the pointer Igor, I've been inventing problem where there's none. igor.vaynberg wrote: > > if you keep your css and your images together in a package and use > relative urls in the css it will work. > -- View this message in context: http://old.nabble.com/How-to-%27resolve%27-URL-in-stylesheet--tp27720293p27741978.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 'resolve' URL in stylesheet?
Hi, I'm wondering if it is possible to 'resolve' URLs in stylesheets so that they would point to packaged resources? Or at least so that they'll work regardless of what /context/ path application is using? Specifically, if I want to use something like in CSS: background-image: url(/images/corner.gif); Can I do something with image URL so that it'll refer to packaged resource or at least will have reference that'll work with any /context/ path (provided, of course, if I put the thing under web/images/corner.gif)? Packaged resources though would be much preferred. Thanks in advance! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Proper way to embed image URL into style attribute?
Hi,
we are currently developing our first application with Wicket -- and
naturally we run into some problems/questions :)
One of the' frameworkish' things we've done is to create 'base page'
that we want to be able switch the look & feel (theme) depending on
the settings (e.g. depending on where/how user is accessing a given
page).
In one of the themes we are using, we want to do a rounded corner on
the dual-colored page. Our designers came up with the HTML that
requires manipulating style attribute on the corresponding div tag,
basically something like:
style="background-image: url(/images/corner.gif); background-repeat:
no-repeat; background-position: right 13px"
Now since this is the 'base page' that will be reused in different
projects we can't hardcode absolute path to the image (at the very
least it is needed to adjust the path based on application context).
Plus to make reuse really easy we decided to store resources
(including images) together with the java/html files.
As far as I could figure out, in this case we need to use
ResourceReference to refer to the resources/images.
I came up with the following code (getWicketVariationContribution()
below returns string that denotes name of the current 'theme'):
OurLookAndFeel lnf = getLookAndFeel();
ResourceReference background =
new ResourceReference( BasePage.class,
lnf.getWicketVariationContribution() + "/images/corner.gif");
String styling = "background-image: url(" + urlFor(background) + ");
background-repeat: no-repeat; background-position: right 13px";
AttributeModifier mod = new AttributeModifier("style", true, new
Model(styling));
content.add(mod);
This seemed to work fine until I've run into some redirect issues with
Internet Explorer.
Basically we have application setup under /context/. We have our
StartPage mapped to 'apply' via:
mount(new HybridUrlCodingStrategy("apply", StartPage.class));
(in production we are going to be using encrypted urls for non-entry
point pages).
The sequence of events if accessed from e.g. Opera is like this:
request: /context/
redirect: /context/apply
request: /context/apply
redirect: /context/apply.0 (and set cookie too)
request: /context/apply.0
response: the page
then there are resource requests etc, everything works normally.
However under IE it is different. First it goes like above for Opera,
but then, suddenly there is the following request:
request: GET /context/apply/wicket:interface/:0::INewBrowserWindowListener::
HTTP/1.0
response: the page is rendered again using the same page instance
I'm guessing that this might be due to a 'new window detection' or
some such. I'm not terribly concerned about the fact though -- but
please let me know if this doesn't work like it should.
The thing I'm concerned with is the style attribute outlined above.
The resulting style attribute looks like this:
style="background-image:
url(resources/wicket.page.base.BasePage/theme/images/corner.gif);
background-repeat: no-repeat; background-position: right 13px"
This works perfectly fine when page url is /context/apply.0, however
it fails completely with page url being in entirely different
'folder': /context/apply/wicket:interface/:0::INewBrowserWindowListener::
Not only it fails to load the image, it also produces exception on the Tomcat:
org.apache.wicket.protocol.http.request.InvalidUrlException:
org.apache.wicket.WicketRuntimeException: Internal error parsing
wicket:interface = resources
I did some experimentation and the problem appears to be due to the
fact that I lock the style contents at page creation time. Since
initially page is created for /context/apply.0 URL (as I said, the
same page instance is reused by Wicket when rendering redirected
'INewBrowserWindowListener' URL)., the created style string is invalid
for redirected URL. When I create similar URL in onBeforeRender() it
results (after redirect) in proper URL:
../../resources/wicket.page.base.BasePage/theme/images/corner.gif
However I don't really want to use onBeforeRender() for populating
page components. It would make (in my opinion) page code less readable
and among other things I'll have to track somehow whether I already
added style attribute before (there's no addOrRemove() method and
remove() method throws exception if can't find what to remove).
At any rate this seems to be a terribly convoluted approach -- I
strongly suspect that I'm missing something obvious here :) Something
as simple as:
link.add(new Image("logoImage"));
that is used to replace image path in HTML with resource-relative image path.
So what would be the proper way to render style attribute dynamically
to include reference(s) to image(s) located together with java/html
files?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
