Wifi/Radius related logic integration #521
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: DioFun <[email protected]> Co-authored-by: Nymous <[email protected]> Co-authored-by: AliasXoX <[email protected]> Co-authored-by: Molymawk <[email protected]>
… are already resources for machines
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #521 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 108 110 +2
Lines 2217 2335 +118
Branches 64 73 +9
==========================================
+ Hits 2217 2335 +118 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Amazing work <3 |
D0gmaDev
requested changes
Aug 15, 2025
Comment on lines
+88
to
+95
| def ensure_has_pseudo | ||
| return unless pseudo.nil? | ||
| return if firstname.blank? || lastname.blank? | ||
|
|
||
| normalized_firstname = firstname.unicode_normalize(:nfkd).gsub(/[^\x00-\x7F]/, '').delete('-') | ||
| normalized_lastname = lastname.unicode_normalize(:nfkd).gsub(/[^\x00-\x7F]/, '').delete('-') | ||
| self.pseudo = "#{normalized_firstname}-#{normalized_lastname}".downcase | ||
| end |
There was a problem hiding this comment.
Fatal issue if two persons share the same name (s/o Manon Perez).
Should fetch the unique username from the SSO (the OpenID claim should be something along the lines of preferredUsername or preferred_username, to check)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The goal of this PR is to implement some logic to integrate a radius server to Lea5.
It has been mostly done by adding new API features and entries to the user table.
Summary of modifications
API features
New route (POST /api/machines) to create machines via API (cf.
machines_controller.rb) : The motivation of this feature was for a new machine to be added to the user account after a successful authentication to the wifiNew route (GET /api/machines) to fetch an index of all the machines (cf.
machines_controller.rb) : The main purpose of this route would be for a DHCP server to fetch all machines from Lea5 and regenerate its configurationQuery param (GET /api/machines?mac=) in order to fetch a machine directly by its mac (cf.
machines_controller.rb) : The obvious purpose of this would be for the RADIUS server to operate a mac-authentication easilyAll json response have been remove from all non-api controllers and jbuilder files have been moved to the api views instead
json format of machines now includes the user (cf
app/views/api/machines/show.json.jbuilder,app/views/api/machines/index.json.jbuilder,app/views/api/machines/_machine.json.jbuilder)json format of users now includes pseudo, internet expiration and ntlm password (wifi password hashed with md4) (cf.
app/views/api/users/_user.json.jbuilder,app/views/api/users/index.json.jbuilder,app/views/api/users/show.json.jbuilder)Navigation to Api Keys management in the header is only accessible by admins (cf.
app/views/layouts/_header.html.erb)The number of machines that can be created via API is also limited (cf.
app/abilities/api_key_ability.rb) : Originally we wanted to make it so admins could add as many machines as they want but it turns out that the admin status is not anchored in the DB but rather determined via the SSO, so the property is not directly accessible by the API. As of today, this limitation seems enough and improvements could surely be achieve beyond the extend of this PR.Wifi related modifications
New entry pseudo in the User table (cf.
app/models/user.rb,app/views/users/_form.html.erb,app/views/users/show.html.erb): The pseudo is the login identifier for wifiNew encrypted entry wifi_password in the User table (cf.
app/models/user.rb,app/views/users/show.html.erb): Since the hash for wifi password is md4 (depreciated and easily breakable by bruteforing) because of the PEAP-MSCHAPv2 authentication protocol, it has been chosen to store the wifi-password in clear (using rails encryption) so it is accessible by user and displayed on the user board (only visible by users, even admins can't see it)MD4 hash code has been implemented by hand in lib (cf.
lib/custom_modules/md4.rb) because it is so deprecated that openSSL doesn't provide it anymore.To not just display the wifi password of a user in clear on the user board it's in a password type input an can be hidden/unhidden and copied (cf.
app/javascript/controllers/user_controller.js,app/views/users/show.html.erb)