Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 23 19:07
    herbertgoto starred Erudika/scoold
  • Jun 23 14:54

    albogdano on master

    readme (compare)

  • Jun 23 14:49

    albogdano on master

    Update README.md to include "ta… Merge pull request #320 from rb… (compare)

  • Jun 23 14:49
    albogdano closed #320
  • Jun 23 14:18
    albogdano closed #319
  • Jun 23 14:18
    albogdano commented #319
  • Jun 23 13:58
    rberends edited #320
  • Jun 23 13:58
    rberends edited #320
  • Jun 23 13:58
    rberends edited #320
  • Jun 23 13:58
    rberends edited #320
  • Jun 23 13:58
    rberends edited #320
  • Jun 23 12:06
    rberends opened #320
  • Jun 23 08:39
    vbyjsue starred Erudika/scoold
  • Jun 23 07:26
    rberends edited #319
  • Jun 23 07:26
    rberends edited #319
  • Jun 23 07:26
    rberends edited #319
  • Jun 23 07:25
    rberends opened #319
  • Jun 23 05:32
    mayur288 forked
    mayur288/scoold
  • Jun 23 05:31
    mayur288 starred Erudika/scoold
  • Jun 23 05:24
    mvandermeulen starred Erudika/scoold
pikrakpzu
@pikrakpzu
@albogdano That's great! Thanks
OrangeBlob
@OrangeBlob
Hi @albogdano, we seem to have lost some of our reputation points on our local scoold environment. Is there a way we can re-generate individual users reputation based on the amount of likes/upvotes they've had on their posts? - We are using MySQL as a backend, so would there be a SQL script we could run to achieve this? Thanks
Alex Bogdanovski
@albogdano
@OrangeBlob check the votes field of each user object in the database and modify it accordingly. Reputation point cannot be recalculated, currently.
pikrakpzu
@pikrakpzu
@albogdano Hi, is it possible to add config that would entirely disable Gravatar integration in next release?
My security team can't stop complaining about that.
Would be great to have a config option to disable gravatar integration at all.
Default image could be hosted by Scoold itself, or have configurable url.
Alex Bogdanovski
@albogdano
@pikrakpzu alright, I'll see what I can do...
what's the problem with Gravatar?
pikrakpzu
@pikrakpzu
@albogdano I won't go into details, but it's about company security rules.
None of our users have permission to register their work email address with Gravatar, so it always use the default image.
Company security statement is: If it is not strictly allowed and required, it must not be used.
Alex Bogdanovski
@albogdano
ok, fair enough
@pikrakpzu you will be able to set para.gravatars_enabled = false once Scoold 1.46.0 is released
pikrakpzu
@pikrakpzu
@albogdano Thank you very much. :)
pikrakpzu
@pikrakpzu
@albogdano Will Scoold Pro get release 1.46.3? Can't find it yet trough AWS CLI.
Alex Bogdanovski
@albogdano
@pikrakpzu it should be release already... give me a sec to check
Alex Bogdanovski
@albogdano
@pikrakpzu for some reason it wasn't released on the AWS ECR repo, but it's there now - sha256:c4de5e305b38470dd593b57a77a767fbfe20f38e07a020030354a396441747b7
pikrakpzu
@pikrakpzu
@albogdano Thanks! :smile:
pikrakpzu
@pikrakpzu
@albogdano I like feedback feature. Does it have an option to make it avaliable only for registeres users?
I see that only registered users can write, but also reading would be nice to respect para.anonymous_posts_enabled = false.
Alex Bogdanovski
@albogdano
@pikrakpzu yes of course, I will have make some changes :thumbsup:
pikrakpzu
@pikrakpzu
@albogdano Awesome! :ok_hand: Thank you.
pikrakpzu
@pikrakpzu

@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?

pikrakpzu
@pikrakpzu
Just to mention: we were upgrading from 1.45.0 :smile:
Alex Bogdanovski
@albogdano
@pikrakpzu there's no particular switch to make that happen. do you mean those users do not have an email in LDAP?
you could perhaps delete their Scoold accounts and if their accounts have no associated posts or reputation, they probably won't notice and would be able to log back in
pikrakpzu
@pikrakpzu

@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:

  1. Users already created - yes, while they have no posts or customized profile photo/settings they won't notic.
  2. Existing users info changed (for example get married and chcnged last name, or changed department included in user name), even email could change.

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.

Alex Bogdanovski
@albogdano
@pikrakpzu that's exactly how Para does it - user info is updated on every sign in request. Users are found by their email address, so if their email has changed in LDAP the user will no longer be found and a new user will be created
pikrakpzu
@pikrakpzu
@albogdano What is use of para.security.oauth.parameters.id = "sub"? That may be the case why users were not updated or recreated trough OIDC, as theirs No Name account had no email specified.
Alex Bogdanovski
@albogdano
@pikrakpzu yes, the sub should not change because when the user is created Para will create a special identifier object with id oa2:sub and will try to find the user based on that id later
pikrakpzu
@pikrakpzu
@albogdano Ok, the sub is same, but email was empty, and now it's set.
User sign in to old account, but his info is not updated.
Is that suspected behaviour?
What if I fill correct email on user in mongo, should it fix, or is email somehow mixed with sub?
Alex Bogdanovski
@albogdano
@pikrakpzu the info should be updated if it has changed since the last login but check the logs and make sure that Para doesn't create a new user
I'm a bit confused - is user data inside LDAP or MongoDB?
you can try to clean up identifier objects in Para - search for oa2:sub objects where sub is the sub ID
you can safely delete those objects in Para for the problematic users
also you can check that the user info is reflected in each Para object of type user for each problematic user
the data flow is: OIDC -> Para user object -> Scoold profile object
Alex Bogdanovski
@albogdano
for each user object there is only one Scoold profile object and multiple identifier objects - one for each identity provider
I guess what happened is this - user with No Name logged in with sub 123 then you changed settings and that same user logged in but now with sub 345 and a new user was created so you now have "dead" user objects which need to be deleted
pikrakpzu
@pikrakpzu

@albogdano AD is a storage for user data, LDAP and 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 | user@company.com | 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:

Perfect, had to edit multiple times to get table rendered right :smile:
Alex Bogdanovski
@albogdano
@pikrakpzu ok, let me know what you find. And, yes MongoDB is used by Para to store data so you are in fact using it.
I am not quite sure how we can fix your problematic users in this situation but definitely check the user objects in Para and if they have the correct user data from OIDC
pikrakpzu
@pikrakpzu

@albogdano At last I had some time to investigate Scoold users.
Looks like there is a problem with profile update.
While user was updated with correct name, profile have old wrong name and new correct originalName.

Method I used to check this.

Search query:
para-cli search "creatorid:ID* OR id:ID*"
Where 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

On profile we have name and originalName.
profile where identifier for ldap was created before oa2 got valid name and originalName seems ok.
profile where identifier for oa2 was created before ldap (and before last update which fixed oa2) got invalid name but originalName seems ok.

Also I have found that long time ago I had different name pattern from ldap like User Name (login) and oa2 is User Name (Office).
My own profile is one of oldest and it has name in old format, but originalName have been updated from oa2.
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.

Alex Bogdanovski
@albogdano
@pikrakpzu yes, there's an option for that - para.name_edits_enabled = false this way, you disable name editing on Scoold and force name updates to be passed on from the identity provider (LDAP or OA2)
the idea is that once a Scoold account is created (type: profile) users can edit their name independently from what's provided by the IDP. For better synchronization, you can turn off that feature and always sync the names
I'm sorry if I forgot to mention that earlier in our conversation... :neutral_face:
could've saved you some time
pikrakpzu
@pikrakpzu
@albogdano That's exactly what I need, i'm glad we finally get to it :smile:
rafik777
@rafik777
@albogdano How to extend the default session duration? Token expiration? I am using LDAP login. I have to sing in too often...
Alex Bogdanovski
@albogdano
@rafik777 for example, set para.session_timeout = 21600 for 6h session duration (in seconds) and restart. In 6h the auth cookie will
expire but the JWT inside the cookie may still be valid. So make sure you also configure Para to issue JWTs with the same
validity period using para.jwt_expires_after = 21600 or by updating your Para app object to have a property tokenValiditySec: tokenValiditySec
se-alexnsa
@se-alexnsa
Hey there. Whenever we restart the para service (in AWS Fargate, using RDS mysql to store database), we have a the server is unhealthy and must be re-indexed/re-built. Each time, we use para-cli rebuild-index and it works - it gets re-indexed and the server is healthy again.
To save us from running that para-cli command every time, will changing the para config to use the para elasticsearch plugin work to prevent that re-indexing error coming up? and will we have to also spin up an AWS Elasticsearch service to use alongside the plugin?
Alex Bogdanovski
@albogdano
@se-alexnsa that is not normal - there must be something wrong with the Par configuration or the search index storage. Are you sure the server is unhealthy because the index has been lost? What's the exact message in the logs?
If you use the ES plugin, you'll definitely need to connect to some Elasticsearch server of your own
se-alexnsa
@se-alexnsa

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.

Alex Bogdanovski
@albogdano
@se-alexnsa I'm pretty sure that your search index is not stored to disk properly. check if the ./data folder is mounted properly as a volume if using docker.