albogdano on master
fixed assets version number sho… (compare)
albogdano on master
fixed git revision should not b… (compare)
albogdano on 1.49.5
@albogdano Scoold 1.46.3 is one of the most awaited updates by my team, and it's really great. :thumbsup:
New users are registering with correct email and username from OIDC.
Thanks to config that supports nested fields:
para.security.oauth.parameters.email = "/attributes/Email" para.security.oauth.parameters.name = "/attributes/DisplayName" para.security.oauth.parameters.given_name = "/attributes/Imie" para.security.oauth.parameters.family_name = "/attributes/Nazwisko"
But one previously registered with
No Name and without email were not updated when sign in on 1.46.3.
Is there any config switch, I could miss, to enable user info updates from OIDC/LDAP?
@albogdano Before support of nested fields user accounts were created with invalid name/email.
Now accounts are created with correct info, but there are two cases:
I think it should get updated at Scoold on every sign in, because that user info is owned by OIDC/LDAP and they are the only source of truth about user.
Worth to notice that we have no
picture config and it's only customizable by user. It would be evil to reset their image to default on every sign in :smiling_imp:
But when our OIDC let us fill
para.security.oauth.parameters.picture = "picture" i would set
para.avatar_edits_enabled = false and expect pictures to get updated on sign in just like other data from identity providers.
oa2:subobjects where sub is the
userfor each problematic user
userobject -> Scoold
123then you changed settings and that same user logged in but now with sub
345and a new user was created so you now have "dead" user objects which need to be deleted
AD is a storage for user data,
OIDC are just different ways to get them.
I could have been wrong about the Scoold users being stored in Mongo (which we use with Para), as You say they are stored in Para. So there's no mongo in process.
OIDC data for para between versions was like:
scoold v. | sub | email | name 1.45.0 | 123 | | 1.46.3 | 123 | firstname.lastname@example.org | Best User (His Department)
Also users were able to sign in their No Name accounts using LDAP wchich has a valid user info.
In fact that was our workaround - first login with username/pass trough LDAP to create Scoold account, then use OIDC wchich supports SSO.
In result they got full user data in Scoold, and sign in with OIDC didn't clear user name or email.
While signed in with opposite order, No Name account were created for Scoold and no info were updated after LDAP sign in to the same account.
I'll try to investigate this more after the weekend.
Thank you for your help and have a nice weekend :smiley:
userobjects in Para and if they have the correct user data from OIDC
@albogdano At last I had some time to investigate Scoold users.
Looks like there is a problem with
user was updated with correct
profile have old wrong
name and new correct
para-cli search "creatorid:ID* OR id:ID*"
ID is a
id field value from result of:
para-cli search "type:user AND email:greatuser*"
For users that used ldap and oa2 to login, result is (excluding posts/queries/votes etc.):
sysprop | identifier | id:ldap:... sysprop | identifier | id:oa2:... type | profile type | user
profile we have
ldap was created before
oa2 got valid
originalName seems ok.
oa2 was created before
ldap (and before last update which fixed oa2) got invalid
originalName seems ok.
Also I have found that long time ago I had different name pattern from
User Name (login) and
User Name (Office).
profile is one of oldest and it has
name in old format, but
originalName have been updated from
Last time I used
oa2 to signin.
Seems that Scoold uses
name field from
profile which is not updated with data from identity providers (ldap, oa2).
I didn't write about
user object as it contains valid name.
If it would help I can paste this objects.
para.session_timeout = 21600for 6h session duration (in seconds) and restart. In 6h the auth cookie will
para.jwt_expires_after = 21600or by updating your Para app object to have a property
Yes, will set up an Elasticsearch server
Regarding the server unhealthy message, it was this
2021-11-02 10:56:11 [WARN ] Server is unhealthy - the search index may be corrupted and may have to be rebuilt.
then after I ran
para-cli rebuild-index, the log message was
[INFO ] Server is healthy.
@se-alexnsa I'm pretty sure that your search index is not stored to disk properly. check if the
./datafolder is mounted properly as a volume if using docker.
We're using AWS Fargate.
When running locally using docker, data is at
I didn't physically mount it, but it was already there when I spun up the container. Do we need to do something differently there?
And how can that be mounted when using Fargate too?
erudikaltd/para-search-elasticsearchimage to our already existing dockerfile?
@albogdano Hello! :)
My organization's security team found few bugs in Scoold.
There's no check of what user set, and its served to all other users as avatar.
User can setup malicious link, containing js code which for exapmle could steal auth tokens from cookies.
As example this URL were given:
scoold-auth with JWT can be stolen and it's valid for 7 days.
Also user session is not closed after logout, with stolen cookie it's possible to get access without login.
para.jwt_expires_after few posts before.
Correct me if i'm wrong, when set to
300 it will make JWT expire after 5min? It should fix 7 days problem.
But it won't solve existing session after logout.
Is there anything that can be done to fix them?
@pikrakpzu Hey, thanks for this! I will work on the code to address these points.
On the first topic: I don't think that's even possible because Scoold has a pretty strict CSP - https://cspvalidator.org/#url=https://live.scoold.com
Security headers are also in place - https://securityheaders.com/?q=https%3A%2F%2Flive.scoold.com&followRedirects=on
There's always room for improvement here and I will soon add filtering of the actual URLs for avatars
On the second topic: Scoold does not use sessions at all - it uses JWTs instead. It's a similar concept and JWTs can be made to expire after a configurable time period.
para.session_timeout is the validity period in seconds for the auth cookie itself,
para.jwt_expires_after is the validity period in seconds for the JWT token inside the auth cookie.
Again, here we can tighten security by only allowing one valid JWT per user/browser. It should be pretty straightforward to implement this.
yes, you need to add the plugin image as a layer on top of the Para Docker image
If I do that, do I still need to download this jar file as well: