Hi Tauren, Glad to help!
And the idea about using this to seed a crypto chapter is a great idea. I would have liked to have gotten to this earlier, but there are only 24 hours in a day :/ (Just a side note for anyone reading this, anyone can contribute to documentation by logging in to the ASF Confluence wiki and contributing pages or attaching text to a Jira issue). Also, our discussion has given me some ideas. For example, SimpleByteSource(String foo) only does one thing - it converts the input (non-encoded) string into bytes (i.e. CodecSupport.toBytes(unencodedString)). Maybe we can add some heuristics to it where we check the argument, and if Base64.isBase64(rawStringBytes) or Hex.isHex(stringRawBytes) we can decode the string first. Otherwise, we use the String as supplied. That might eliminate many decoding confusion issues. I also thought of a ByteSource.Builder inner class to build ByteSource instances instead of forcing an implementation class (SimpleByteSource) on end-users. This has been helpful for me too! ;) Thanks, Les On Fri, Apr 8, 2011 at 12:26 AM, Tauren Mills <tau...@groovee.com> wrote: > Les, > I wanted to thank you for your help with all this. I'm now successfully > encrypting and decrypting values that I can get and set to my persistence > system as string values. Your assistance was invaluable, and the information > in this thread might be a nice start to the Shiro crypto user manual. > Thanks again, > Tauren > > On Tue, Apr 5, 2011 at 11:59 PM, Les Hazlewood <lhazlew...@apache.org> > wrote: >> >> Finally, I think a lot of your frustration can be cleared up by 2 >> simple guidelines: >> >> 1. You shouldn't ever really need to call aString.getBytes() or >> aByteSource.getBytes(). >> >> 2. If you need bytes-->string or string-->bytes behavior (reading >> from files or the database and vice versa), you can do that simply: >> >> a. bytes --> string: aByteSource.toBase64(); >> b. string --> bytes: Base64.decode(base64EncodedString); >> >> Those two things should probably get you all you need. Anything else >> will probably just cause confusion. >> >> HTH, >> >> Les
