ok, great!
I think I can wait for the next RC, as this app is still in
development, and I can remove (and later re-add) those = in the
database manually for now.
--
greetings from Berlin,
Rüdiger Schulz
Martijn Dashorst wrote on 19.04.2006 at 00:29:
In the next RC this problem will be
it is not just the =we use a different base64 set where + and / are - and _ so that urls can handle them.http://www.faqs.org/rfcs/rfc3548.htmlThe best thing to do is convert to SHA one way encryption for passwords.
johanOn 4/19/06, Rüdiger Schulz [EMAIL PROTECTED] wrote:
ok, great!I think I can
Johan Compagner wrote on 19.04.2006 at 12:11:
it is not just the =
we use a different base64 set where + and / are - and _ so that urls can
handle them.
http://www.faqs.org/rfcs/rfc3548.html
The best thing to do is convert to SHA one way encryption for passwords.
You're probably right
the problem with including this into a ui framework.. is that it doesn't really belong thereBecause encrypting strings and storing in the db is something of the businesslayer not a ui thing.johan
On 4/19/06, Rüdiger Schulz [EMAIL PROTECTED] wrote:
Johan Compagner wrote on 19.04.2006 at 12:11: it
Johan, may be you can create a little ICrypt implementation for that?
As it is one way, decrypt should probably throw an exception
Juergen
On 4/19/06, Rüdiger Schulz [EMAIL PROTECTED] wrote:
Johan Compagner wrote on 19.04.2006 at 12:11:
it is not just the =
we use a different base64 set
But how to use that? Because we only have 1 crypt instance/factory that could be usedfor crypting/decrypting stuff in wicket itself (like password or cookies)So there you can't just set one that works only one way.
johanOn 4/19/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
Johan, may be you can
import java.io.UnsupportedEncodingException;import java.security.MessageDigest;import java.security.NoSuchAlgorithmException;import wicket.util.crypt.ICrypt;public final class OneWayCrypt implements ICrypt
{ /** * One way encryption only, throws UnsupportedOperationException. * * @see
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
you mean PasswordTextField.getModelValue()?getModelObject() should return the thing you feed it. (that is by default not encrypted but just a string)But yes there is some changes in the base64 encodig that is done on top of the crypting.
I think we are still discussing what should be the end
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
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.
I think Johan is right. We originally added base64 de/encoding to
AbstractCrypt because crypted URLs didn't work properly (due to chars
not allowed in URLs). Unfortunately RFC2054 base64 encoding as
implemented by apache and used by wicket until now is not suitable as
well as it it uses / and +
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
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
I propose the following:introduce wicket.util.crypt.Base64Rfc3548, implementing the current Base64 as in rc1make wicket.util.crypt.Base64 class Rfc2045 compliant as it was before rc1create a new method on AbstractCrypt that does the url-safe encoding using Base64Rfc3548
document that it is not
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
Rüdiger,In the next RC this problem will be fixed, and you'll get the = back in the string.If you need it earlier, you can check out wicket trunk and build your own wicket version.
MartijnOn 4/18/06,
Rüdiger Schulz [EMAIL PROTECTED] wrote:
Hello list,for a Wicket-application requiring a signed-in
17 matches
Mail list logo
