¿link de confirmacion en mi correo?

Hola, tu duda es en cuanto al como mandar correo, o al como procesar el correo?, si es la segunda opcion, te puedo dar una idea.
en el link de confirmacion puedes tu utilizar a traves del query de URL informacion que te sera utilizada al momento de procesar dicha peticion,
ej.

donde en AltaUsuario es tu aplicacion y le mandas como parametro el id de usuario o cualquier otra informacion, esta puede ya estar procesada con algoritmos de codificacion para que no sea tan facil adivinar que el id de usuario sera 1234 o algo asi. weno es lo que se me ocurre.

En cuanto al como mandar el correo, ya existen varias preguntas en foros y asi aqui mismo. solo dale una busquea (sorry no puedo yo).

Espero y te ayude mi tip, pero espera haber si alguien de mas experiencia te da otra opinion y me corrigen en algo.

Saludos

pues yo lo que haria seria que e la tabla usuario manejaras un estado que indique el "estado de la cuenta que se creó" asi podras definirla si esta activa, inactiva, cancelada ... y lo que necesitas "confirmada" (por asi llamarle)

Puedes enviar un simple correo con la liga y lainformacon e claro (cosa que no es muy recomnedable)... lo que yo te sugiero es que pongas "id+usuarioNombre+contraseña+loquequieras" y lo cifres (y despues lo conviertas a base 64 para que puedas meterlo en una URL)

No hagas algun tipo de resumen para que puedas hacerel proceso inverso. Ai me imagino que quedaria tu mail
 

cuand llegue a tu servidor (que la hayan dado click) pues haces lo inverso, decodificas lo que tienes en base64 y despues "desencriptas" (cielos, aqui viene @ezamudio corrigiendo mi pochismo jejeje) y despues tienes el texto original... haces un split con el caracter + y tenes la informacion... la validas y si es correcto pues que crees? activas la cuenta con el estado que temencionaba (considera el estado en el inicio de sesion)

Para que son varios campos? pues para despistar al enemigo y lasemilla que le pones al final es para que le amarre un poco mas de seguridad (es una semilla) y recuerda que eso debe ser tambien secreto

pues funcionalmente asi lo haria... habra que investigar esas cosas que no sepamos para implementarlo

nota, para pasarlo por una URL ten presente este comentario (y el post completo):

Si lo haces en Base64 se puede decodificar y re-codificar muy fácilmente y da lo mismo que se mande en plano.

Por ejemplo StackExchange lo hace así:

Y el URL que te mandan es algo como esto:

Lo que puedo entender que hacen es que cuando haces la petición, dejan un cookie en tu browser de tal forma que cuando le das click al link, validan que tengas esa cookie y junto con el token forman un nuevo numero. Quizá después de ahi buscan un registro en la su base de datos con ese nuevo número

Y si se encuentra una petición en el registro indicado por la llave te presentan la pantalla de password reset:

Si no se encuentrá el cookie ( por ejemplo cuando pego el mismo link en otro navegador )

Sale esto:

Wordpress hace algo similar pero ellos te mandan los dos valores, el token y el usuario, de cualquier forma el usuario se puede usar como sal para generar un nuevo número.

En términos generales es mejor que este tipo de cosas sean de una sola vía ( que se puedan codificar pero no descodificar )

El término con que lo puedes buscar en google es:

Ahi nos platicas como lo hiciste.

está muy bueno eso de usar cookies... por cierto, en Europa ya está prohibido usarlas sin permiso explicito del usuario (consideralo si quieres que se registren desde allá)

@oscarRyz lo de pasarlo a base 64 es para que el binario (resultado del cifrado yasea por RSA, DSA, 3DES...) no se mande como tal pues hay caracteres que se pierden si los muestras como son y el objetivo de usar b64 es justo que se pueda cifrar y lo inverso... pero lo que tengas de eso tienes que hacer todavia la "desencriptacion" asi pues que no estarias mandando texto plano (solo es la representacion para no mandar los bytes crudos)

Ahh ya eso si, creí que querías pasar: "name=Oscar&value=password" a base 64 lo cual pues no iba a ser nada seguro.

Generas un token y lo guardas asociado al Usuario (puede ser una columna en la misma tabla de usuarios o una aparte). El token pueden ser simplemente 64 bits aleatorios, los codificas en base64 para guardarlos como texto y lo almacenas asociado con el usuario.

Luego generas una liga como han mencionado java.daba.doo y Oscar, pero la liga no lleva esos 64 bits, sino que generas algo distinto: concatenas el email del usuario con los 64 bits, le sacas un MD5, y eso es lo que pones en la liga, que va a un servlet o JSP o acción o lo que sea en tu aplicación. Además de eso, debe venir el identificador de usuario (puede ser nuevamente el email).

Cuando recibes la petición en donde corresponde en tu app, comienza un proceso que si falla cualquier paso entonces NO está verificada la cuenta:

1. Obtienes la cuenta que indica el email (que viene en un campo de la petición). Debe estar en status de pendiente de activación.
2. Obtienes los 64 bits codificados en base64
3. Decodificas esos bits, concatenas el email de la tabla con esos bits y les sacas un MD5
4. Comparas el MD5 que acabas de generar con el que viene en la petición. Si son idénticos, la cuenta está verificada y la puedes activar.

Si quieren pueden mirarlo en mi blog :
MiBlog