I don't care either, as long as we don't re-introduce something that is broken just to be backwards compatible. So whatever problem this fixed in the first place, that should stay fixed. If we can do that in a backwards compatible way without clutering the API, that's all the better.
Eelco On 4/18/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > I'm at a point where I don't care anymore. We can revert it assuming > (based on ICrypt API) that we always encrypt String and expect valid > Strings after decrypt, than we need some base64 encoding and if for > whatever reason that must be RFC2xxx compliant, than it must RFC2xxx > compliant. URLs can be encoded the ICrypt encoded string to make sure > they url compliant. > > Juergen > > On 4/18/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > yes crypting and base encoding shouldn't be the same thing > > > > Or is it that we use it always where crypting is used? For example cookie > > values > > must those be encoded or not (i do think that we should be secure by default > > and always encrypt them) > > > > If we come to the conclusion that we do use encoding everytime when we > > encrypt then i am with eelco and > > let it be what it is now. If we come to the conclusion that this isn't the > > case then remove it completely. > > > > johan > > > > > > > > > > On 4/18/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > > > That is not true. We introduced base64 because the encrypted strings > > weren't URL compliant. And than we detected that sun/apache/rfc2054 > > base64 encoding doesn't do the job either. But you agree with removing > > it completely out of Crypt and not doing any base64 in AbstractCrypt. > > > > Juergen > > > > On 4/18/06, Martijn Dashorst < [EMAIL PROTECTED]> wrote: > > > The bug is introduced by the fix for the url encoding. Not the other way > > > round. This one should be rolled back, and the URL encoding should be > > fixed > > > in a different manner. > > > > > > Also, the Wicket 1.1 encryption used the Sun BASE64Encoding, which is also > > > RFC2045 compliant. Our base64 implementation should reflect that and we > > > should implement a separate encryption schema for URL's. > > > > > > Martijn > > > > > > > > > On 4/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > I don't know whether it is such a good idea to 'unfix' a bug just for > > > > compatibility. It was fixed because people were experiencing problems > > > > with it, right? So unfixing it will give those users those problems > > > > again. > > > > > > > > Eelco > > > > > > > > On 4/18/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > > > Yes that is true. We most likely change it back. The reason it has > > > > > been changed is because / and + are not allowed in URLs and we use the > > > > > same encryption algorithm for URL encryption .... Though we used a > > > > > (old) standards compliant base64 encoder/decoder it is not URL > > > > > compliant. The new standard (RFC 3xxx) is slightly different and the > > > > > one rc1 is using. rc2 will be out pretty soon I guess and I assume we > > > > > change it back (for compatibility reasons only) and find some other > > > > > solution for URLs > > > > > > > > > > Juergen > > > > > > > > > > On 4/18/06, Rüdiger Schulz <[EMAIL PROTECTED]> wrote: > > > > > > Hello list, > > > > > > > > > > > > for a Wicket-application requiring a signed-in user I use > > > > > > PasswordTextField.getModelObject() for acquiring > > the > > > entered data. > > > > > > Going the easy way, I simply stored this in the database, as it was > > > > > > already encrypted, and comparison during login is also very easy to > > > > > > do. > > > > > > > > > > > > Now I upgraded from wicket 1.1.1 to 1.2rc1. This method still works, > > > > > > but something has changed. Before, all passwords had a '=' as their > > > > > > last character, which they now lack. Apart from that, the encryption > > > > > > seems to produce the same encrypted strings out of the source > > strings. > > > > > > > > > > > > If this is not a bug, it should be stated in the migration guide > > > > > > somewhere... > > > > > > > > > > > > -- > > > > > > greetings from Berlin, > > > > > > > > > > > > Rüdiger Schulz > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > This SF.Net email is sponsored by xPML, a groundbreaking scripting > > > language > > > > > > that extends applications into web and mobile media. Attend the live > > > webcast > > > > > > and join the prime developer group breaking into this new coding > > > territory! > > > > > > > > > > > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642 > > > > > > _______________________________________________ > > > > > > Wicket-user mailing list > > > > > > Wicket-user@lists.sourceforge.net > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.Net email is sponsored by xPML, a groundbreaking scripting > > > language > > > > > that extends applications into web and mobile media. Attend the live > > > webcast > > > > > and join the prime developer group breaking into this new coding > > > territory! > > > > > > > > > > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642 > > > > > _______________________________________________ > > > > > Wicket-user mailing list > > > > > Wicket-user@lists.sourceforge.net > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email is sponsored by xPML, a groundbreaking scripting > > > language > > > > that extends applications into web and mobile media. Attend the live > > > webcast > > > > and join the prime developer group breaking into this new coding > > > territory! > > > > > > > > > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642 > > > > _______________________________________________ > > > > Wicket-user mailing list > > > > Wicket-user@lists.sourceforge.net > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > > > > > > > > > > > > > > -- > > > Wicket 1.2 is coming! Write Ajax applications without touching JavaScript! > > > -- http://wicketframework.org > > > > > > ------------------------------------------------------- > > > > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > > that extends applications into web and mobile media. Attend the live webcast > > and join the prime developer group breaking into this new coding territory! > > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642 > > _______________________________________________ > > Wicket-user mailing list > > Wicket-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642 > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
