hubssolib 3.7.0 → 3.7.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/CHANGELOG.md +2 -1
- data/Gemfile.lock +1 -1
- data/README.md +74 -0
- data/hubssolib.gemspec +1 -1
- data/lib/hub_sso_lib.rb +7 -0
- metadata +1 -1
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 68326a50593cfc8b53f1d5ba20e668a0a18316d8e3c6f9a9b245f213522f46f7
|
4
|
+
data.tar.gz: 9267e261fb2af094e0801cea965007c8ee5760d93886a3525640ecca5603f52a
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 1849bcd713bb28f152fae7ca328f0d5f9cbb3b49aef31485019e930ba083af8f79cc3f804d04cf81628aed1bcfdbf669acada4c9cf97b2d190eefe4bc4cf6e9d
|
7
|
+
data.tar.gz: 22c27953133bda55f46e83636298a7b978480bf2d05160a22caf16cecdf4579d39ddff294185dc8510e415fa94a04bd087a6875a983c6cf3df0238e4eac647ee
|
data/CHANGELOG.md
CHANGED
@@ -1,7 +1,8 @@
|
|
1
|
-
## 3.7.0, 28-Mar-2025
|
1
|
+
## 3.7.0 and 3.7.1, 28-Mar-2025
|
2
2
|
|
3
3
|
* Login indicator cookie wasn't updated on session timeout, so when the page loaded for pages that do *not* require authorisation, the warning flash about being timed out would show, but the indicator would still show a "logged in" state until the next page fetch.
|
4
4
|
* User trust mechanism introduced, including HubSsoLib::Core#hubssolib_trusted? convenience accessor for Hub-integrated applications to check on user trust and `HubSsoLib::Core#hubssolib_review_action` convenience alias for `HubSsoLib::Trust.get_trust_object().review_action`.
|
5
|
+
* 3.7.1, released only a few minutes after 3.7.0, added the aforementioned `#hubssolib_retrieve_action` method, previously overlooked.
|
5
6
|
|
6
7
|
## 3.6.1, 27-Mar-2025
|
7
8
|
|
data/Gemfile.lock
CHANGED
data/README.md
CHANGED
@@ -376,3 +376,77 @@ In the example of "permissions for arbitrary user" you may well not have ready a
|
|
376
376
|
When a user logs in with a traditional log-in system, there's usually some message shown on the page presented when log-in is successful. This is achieved through the Hub equivalent of the Rails `flash` hash. Replace your preferred mechanism for including contents of the `flash` hash into your views (usually via one or more layout files) with an equivalent which calls Hub's flash handling code, which aggregates both current application and cross-application flash content into one.
|
377
377
|
|
378
378
|
Just using `<%= hubssolib_flash_tags -%>` in your layout(s) and/or view(s) will output merged flash data. HTML is generated consisting of `h2` tags with class names derived from the keys used in the flash tag. Each heading tag encapsulates the value for the key and is followed by an empty paragraph tag for spacing reasons on older browsers when more than one key is present, though normally there is only one. Hub itself commonly uses keys `:notice` ("green" / general information - e.g. "you are now logged in"), `:attention` ("orange" / something unusual happened - e.g. "your session timed out so you were logged out") and `:alert` ("red" / something bad happened - e.g. "incorrect password given").
|
379
|
+
|
380
|
+
|
381
|
+
|
382
|
+
## Trust mechanism
|
383
|
+
|
384
|
+
Hub 3.7.0 and later introduce a trust mechanism. Users have a "trusted" flag that's off by default for any new user. Participating applications can check the current user trust with `hubssolib_trusted?`. For actions where you care about trust - which are typically for creations (e.g. post to a forum, comment on an article) then:
|
385
|
+
|
386
|
+
* The relevant controller action proceeds as normal to the point of being ready to save new or updated record(s)
|
387
|
+
* If the user is untrusted and the to-be-saved record(s) is/are valid, and so should save OK...
|
388
|
+
- ...instead assemble information about the action and send it to Hub
|
389
|
+
- ...and *do not* save anything but instead exit with an appropriate flash message (e.g. "Thanks, that's gone into our moderation queue and should show up soon - please check back later!").
|
390
|
+
|
391
|
+
You send an action to Hub with an alias method `hubssolib_review_action` which has this effective signature:
|
392
|
+
|
393
|
+
```ruby
|
394
|
+
def hubssolib_review_action(
|
395
|
+
user_email:,
|
396
|
+
action_scheme:,
|
397
|
+
action_url:,
|
398
|
+
action_payload:,
|
399
|
+
action_as_html:,
|
400
|
+
callback_url:
|
401
|
+
)
|
402
|
+
```
|
403
|
+
|
404
|
+
...where you pass:
|
405
|
+
|
406
|
+
* The user's email address _as known to Hub_, which is used to look up the user on the Hub side
|
407
|
+
* The HTTP method that was being used as a string, case insensitive, e.g. `POST`, for display to admins only
|
408
|
+
* The URL in full upon which this current request was made, for display to admins only
|
409
|
+
* The payload - usually just `params`, as-is - you'll get send this back again later, so include everything you need to reprocess the action
|
410
|
+
* Your choice of **safe** HTML that the Hub application will show as a preview (this may undergo some allow-list sanitisation; Hub does not expect a malicious integrated application to send it bad HTML which attempts skullduggery, but it shouldn't compromise its view layer just because something unsafe got sent accidentally, either!)
|
411
|
+
* **A callback URL** described below
|
412
|
+
|
413
|
+
If an admin thinks that the submission is bad - e.g. spam - then you won't hear about it again. Otherwise, the admin thinks the delayed action should now be taken for real. To accomplish this, Hub will `POST` back (and always uses `POST`) to your `callback_url` **in JSON** with an object that just has a key, `id`.
|
414
|
+
|
415
|
+
You create a controller action for your endpoint which retrieves the action details using code similar to this:
|
416
|
+
|
417
|
+
```ruby
|
418
|
+
# The request format might be JSON because ".json" ended the path of the
|
419
|
+
# URI used to call here, but a missing or incorrect Content-Type header
|
420
|
+
# may mean that Rack/Rails doesn't process the body into "params" as
|
421
|
+
# expected. The latter would result in a nonsense database lookup which
|
422
|
+
# is harmless but wasteful, so don't do it.
|
423
|
+
#
|
424
|
+
if request.format.json? && request.headers['Content-Type']&.downcase == 'application/json'
|
425
|
+
@details = hubssolib_retrieve_action(id: params[:id])
|
426
|
+
head :unprocessable_entity if @details.nil?
|
427
|
+
else
|
428
|
+
head :unsupported_media_type
|
429
|
+
end
|
430
|
+
```
|
431
|
+
|
432
|
+
...then uses the object to work out what to do next. The retrieved object is a Hash, with **Symbol keys at the top level** but **String keys in `action_payload`**:
|
433
|
+
|
434
|
+
```
|
435
|
+
{
|
436
|
+
timestamp: untrusted_action.created_at,
|
437
|
+
user_email: untrusted_action.user_email,
|
438
|
+
user_unique_name: user_unique_name,
|
439
|
+
action_scheme: untrusted_action.action_scheme,
|
440
|
+
action_url: untrusted_action.action_url,
|
441
|
+
action_payload: untrusted_action.action_payload
|
442
|
+
}
|
443
|
+
```
|
444
|
+
|
445
|
+
...so that's:
|
446
|
+
|
447
|
+
* The created-at time when you sent the action for review. This is usually only needed if you're dealing with a delayed edit/update action, where you might need to make sure that nobody else had edited the same entity in the mean time.
|
448
|
+
* The previously submitted user e-mail is given so you know _who_ it was that is now being trusted, along with the associated Hub "unique display name" (e.g. `Jane Doe (14510)`).
|
449
|
+
* Your previously submitted action scheme and URL are also given in case you need them because you've decided to implement one callback handler for different kinds of untrusted action.
|
450
|
+
* The `action_payload` is where all your important data, meaningful only to you, resides and this must contain everything else, other than the above parameters, required to complete the action previously sent for review, _while making sure things are attributed to the correct user_.
|
451
|
+
|
452
|
+
The trust mechanism involves a fair amount of effort on the integrating app's side but it can be very useful if you have a site where, despite your best efforts, sometimes spam/bot accounts manage to get inside and try to flood the system with spam. It's just one of many different potential protection and mitigation mechanisms that your site might choose to employ.
|
data/hubssolib.gemspec
CHANGED
data/lib/hub_sso_lib.rb
CHANGED
@@ -1092,6 +1092,13 @@ module HubSsoLib
|
|
1092
1092
|
HubSsoLib::Trust.get_trust_object().review_action(**args)
|
1093
1093
|
end
|
1094
1094
|
|
1095
|
+
# The equivalent of #hubssolib_review_action, but for retrieving details of
|
1096
|
+
# an action when Hub invokes your callback via POST request.
|
1097
|
+
#
|
1098
|
+
def hubssolib_retrieve_action(**args)
|
1099
|
+
HubSsoLib::Trust.get_trust_object().retrieve_action(**args)
|
1100
|
+
end
|
1101
|
+
|
1095
1102
|
# Public read-only accessor methods for common user activities:
|
1096
1103
|
# return the current user's roles as a Roles object, or nil if
|
1097
1104
|
# there's no user.
|