Explain how Wicket's CryptoMapper protects bookmarkable page URLs from tampering?

CryptoMapper wraps another request mapper (typically the default one) and encrypts the URL segments it produces, so a bookmarkable page's parameters aren't visible or editable as plain text in the address bar — useful when a URL parameter shouldn't be something a user can freely guess or modify, like an internal record ID that would otherwise let someone probe for other IDs by incrementing a number in the URL.

When mounted, requests going through a CryptoMapper-wrapped mapper get their underlying path and parameters serialized, then encrypted (by default using a symmetric cipher keyed to the application) into an opaque string that becomes the actual URL segment shown to the user. On the way back in, the mapper decrypts that string to recover the original path and parameters before handing off to the normal page-construction logic — the rest of the framework never has to know the URL was encrypted at all, since decryption happens transparently at the mapping layer.

Because the encrypted string can't be edited into something meaningful without the application's key, this closes off a class of tampering where a user might otherwise guess at or manipulate raw ID-based URL parameters to access data or pages they weren't given a legitimate link to — though it's a defense against casual URL guessing and tampering specifically, not a substitute for actual authorization checks on what the resulting page or data access is allowed to show.