Manejo de sesiones sobre el IPC – Parte 1
By s4pcademy
Introducción:
Hola a todos, En esta serie de blogs, explicaré el manejo de sesiones en CPI con la ayuda de un servidor HTTP que se ejecuta en NodeJS en mi computadora portátil personal (es decir, en cualquier lugar en este blog, se hace referencia a mi sistema personal). Cloud Connector se utiliza para conectar el inquilino de prueba de CPI con mi servidor de nodo.
Diagrama de flujo simple
Requisitos previos:
1. Sistema CPI (usé una cuenta de prueba)
2. Cloud Connector instalado en su local.
3. Servidor HTTP NodeJS ejecutándose en mis instalaciones (con manejo de sesiones)
4. Conocimientos básicos del IPC
Descargo de responsabilidad / Puntos a tener en cuenta:
1. No explicaré el código NodeJS en su mayor parte ya que desviará el blog de su dirección original. Agregué un comentario que se explica por sí mismo. Si tiene alguna consulta sobre el mismo, haga ping en el comentario.
2. El requisito utilizado para esto se creó exclusivamente para el propósito de este blog. Entonces, en cierto punto, es posible que sienta que el requisito no es realista. Mi objetivo es explicar la funcionalidad del manejo de sesiones.
¿Qué es una sesión HTTP?
Sáltate la parte si ya lo sabes.
Como sabes, HTTP no tiene estado. Esto significa que no mantendrá ningún estado entre el servidor y el cliente. Cada solicitud del servidor será tratada como una nueva solicitud.
Por ejemplo: si un sitio web de compras en línea le solicita que inicie sesión para cada visita a la página o cada acción que realice, imagine un sitio web HTTP sin estado como este. Pero no estamos haciendo esto; ¿cómo? Porque con la ayuda de cosas como sesiones (es decir, también hay más métodos).
La sesión ayudará a que HTTP parezca con estado. La sesión será almacenamiento del lado del servidor.
Cuando se autentique por primera vez en el servidor, le emitirá un ID de sesión (una cadena larga y aleatoria). El servidor almacenará sus datos en el backend junto con una larga cadena aleatoria. Entonces, en futuras solicitudes posteriores, adjuntará ese ID de sesión como una cookie; si fue una sesión válida, el servidor le otorga acceso.
Diagrama de flujo simple
Adaptadores compatibles:
Puedes ver los adaptadores compatibles en este blog.
Estamos utilizando un adaptador de receptor HTTP.
Configuración del conector de la nube:
Hay una cosa más ahí. Si ve http://locahost:8086 configurado en dos hosts virtuales. Uno lo instalé durante mi primera preparación y el segundo lo hice para el blog.
Si ve el dominio en el código js del nodo siguiente, puede ver el host local configurado allí en el código de sesión. por lo tanto, si está asignando el mismo host interno (con el mismo puerto o diferente) a más de un host virtual, el dominio virtual en la cookie se configurará incorrectamente, lo que no conducirá a que se seleccione la cookie en el lado del CPI.
Entonces, agregué un dominio de cookies como este.
sin esto (elección incorrecta del dominio virtual en la cookie)
con este
Configuración del nodo JS:
- /ruta de inicio de sesión: se utiliza para iniciar sesión.
- /getemployeedetails: se utiliza para obtener detalles de los empleados (Usuario: SAPCPI)
- /getcustomerdetails: se utiliza para obtener detalles del cliente (Usuario: SAPCPI)
- /getpaiddetails: se utiliza para obtener detalles de pago (Usuario: SAPCPI_ADMIN).
const express = require('express')
var parser = require('body-parser')
var session = require('express-session')
const expressApp = express(); // Created Express App
//URL PARSING Middleware
expressApp.use(parser.urlencoded({
extended: true
}))
//JSON PARSING Middleware
expressApp.use(parser.json());
// SESSION Middleware
expressApp.use(session({
secret: 'dsufhodsfhdiajdbadkjbaoodhdjbfadljqslvsoif', // Usually a long secret maintained in environment. For testing I maintained here
cookie: {
httpOnly: true, // Prevent reading the cookie from other than HTTP
maxAge: 150000, // Validity of session on milliseconds
domain: 'localhost' // Domain for cookie
},
resave: true,
saveUninitialized: false,
name: 'Session_ID' // Name on session id cookie on response
}))
//Login Route
expressApp.get("/login", function (req, res, next) {
console.log(req.session.id)
if (req.session.loggedin) { // IF already loggedin
res.status(200).send({
"message": "Session Authorized succesfully"
})
}
else {
const auth = new Buffer.from(req.headers.authorization.split(' ')[1], 'base64').toString().split(':'); // Getting user name and password from auth header
const user = auth[0];
const pass = auth[1];
if (user == "SAPCPI" && pass == '12345') { // For simplicity purpose
req.session.userid = req.body.userid // user id property
req.session.loggedin = true; // Logged In
res.status(200).send({
"message": "Logged In succesfully and session set for 1 hour"
})
}
else if (user == "SAPCPI_ADMIN" && pass == '98765') {
req.session.userid = req.body.userid
req.session.loggedin = true;
req.session.loggedinadmin = true;
res.status(200).send({
"message": "Logged In succesfully and session set for 1 hour"
})
}
else {
res.status(401).send({
"message": "Invalid Credentials. Please try again"
})
}
}
});
// Employee Details
expressApp.get('/getemployeedetails', function (req, res) {
console.log(req.headers.cookie)
if (req.session.loggedin) {
res.status(200).send({
"meessage": "Here you can found employee details"
})
} else {
res.status(401).send({
"message": "Unauthorized. Please login"
})
}
})
// Customer Details
expressApp.get('/getcustomerdetails', function (req, res) {
console.log(req.headers.cookie)
if (req.session.loggedin) {
res.status(200).send({
"meessage": "Here you can found vendor details"
})
} else {
res.status(401).send({
"message": "Unauthorized. Please login"
})
}
})
// Payment details
expressApp.get('/getpaymentdetails', function (req, res) {
if (req.session.loggedinadmin && req.session.loggedin) {
res.status(200).send({
"meessage": "Here you can found payment details"
})
} else {
if (req.session.loggedin) {
res.status(401).send({
"message": "You have no access to payment data.Contact Admin"
})
} else {
res.status(401).send({
"message": "Unauthorized. Please login"
})
}
}
})
expressApp.listen(8086, function () {
console.log("Server Listening on http://localhost:8086")
});Tipos de manejo de sesiones:
Hay 3 tipos
1. Ninguno – La sesión no se reutilizará.
2. En intercambio – La Sesión será válida bajo un solo mensaje.
3. Sobre el flujo de integración – La sesión será válida en todo el i-flow.
Ninguno:
Como sugiere el nombre, la sesión no se reutilizará. Era la opción predeterminada.
Llamé a la ruta de inicio de sesión que realmente inicializa la sesión y la devuelve como una cookie. Necesitamos enviar esa cookie cuando se solicite nuevamente para utilizar la sesión. Activé el punto final de Postman.
Se espera que el resultado sea 401 ya que seleccionamos la sesión HTTP Reutilizar como ninguna. Aunque en el lado del nodo se inicializó la sesión, en el lado del CPI no se reutilizó en llamadas posteriores.
Sobre el intercambio de mensajes:
Adivinaste que tenemos que cambiar en Message Exchange. Eso solucionará el problema. Sí pero no sólo eso.
Implementado y terminó con el mismo error. Ahora recuerde la definición, válida para un intercambio de mensajes. Lo que significa que el área resaltada fue su validez.
¿Cómo lo hacemos como un intercambio de mensajes?
Conviértalo en una llamada de proceso local como esta.
No solo podemos usar esto para procesar llamadas, llamadas en bucle y multidifusión.
Probemos esto y ahora llegó el resultado.
¿Pero esto realmente utiliza una sesión? Lo comprobará llamando nuevamente al punto final. Si ve que se generó la nueva ID de sesión. No fue mi comportamiento esperado. En llamadas posteriores, tenemos que usar la misma sesión hasta que caduque, para eso.
Sobre el flujo de integración:
Lo cambié a Flujo de integración.
En llamadas posteriores, si ve, se utilizó la misma sesión.
–X–
Ahora considere el escenario: necesita consumir dos servicios con un usuario normal y un servicio con un usuario administrador. (Aunque el administrador también tiene acceso a los servicios de usuario normales, imagine que hay una restricción como que el administrador solo pueda acceder a sus servicios relacionados). Así que ahora está desacoplado.
Podemos ir de dos maneras.
1. Si vamos con «en el intercambio de mensajes», cree un proceso de dos locales y llame a cada uno por separado. Pero como se mencionó, generará una nueva sesión con cada visita.
2. Si vamos con “Sobre el flujo de integración” puedes mantener una sesión para un usuario; si pasamos esa cookie a otra, arrojará un error. Tuvimos que cerrar sesión en esta sesión e iniciar sesión nuevamente para otro servicio, lo cual no fue un uso adecuado de una sesión.
Como manejamos esto? Compartamos esto en la segunda parte de este blog.
Agradezco sinceramente cualquier comentario/comentario/pregunta/claridad, no dude en comentar.
Gracias
