Closed a22iliru closed 6 months ago
The documentation says this: This function is currently housed in session.php and might therefore not be something that should be transitioned to a micro service.."
And when looking at the code of the hasAccess function, the code executed by it also makes a call to another function in session.php (getAccessType
). So if this where to be implemented as a microservice, it would still not be isolated from session.php. My opinion is that we need to decide if would should move all used parts of session.php into microservices, or if it should remain in session.php
• Login (login, checklogin, failedLoginCount, addlogintry) • User status (isSuperUser, isTeacher, isStudentUser) • Security question (getQuestion, checkAnswer) • Password (requestChange, standardPasswordHash, standardPassWordNeedsRehash) • Access (hasAccess, getAccessType) • Other (git_checklogin, showLoginPopup)
I am not sure yet whether sessions.php should be split into microservices, but if so this grouping could be an alternative or at least a stepping stone.
The code at the start of the file which sets the cookie parameters could perhaps be its own microservice as well.
Something to consider when grouping these functions into microservices is not only which functions are related to the same functionality, but also which functions are frequently used together. Looking at the current use of these functions will provide a feel for how they might be used in the future. This is important to know in order to avoid neeedless complexity from making the microservices too small or not getting the benefits of the microservices (such as scalability) because they are too big. My grouping is purely based on functionality, so that is something to look into further. In any case, I think that hasAccess and getAccessType together should constitute a microservice.
The group decided to leave sessions.php as it is.
https://github.com/HGustavs/LenaSYS/blob/g2-2024-v4/backend-models/microservices/duggaSys%20services/Microservices.md