summaryrefslogtreecommitdiff
path: root/lib
AgeCommit message (Collapse)Author
2022-07-14Add privilege for announcementsIlja
2022-07-14Merge branch 'develop' of https://git.pleroma.social/pleroma/pleroma into ↵Ilja
fine_grained_moderation_privileges
2022-07-13Merge branch 'short-description' into 'develop'tusooa
Add short_description instance field Closes #2865 See merge request pleroma/pleroma!3651
2022-07-11Merge branch 'fix/case-sensitivity-restricted-nicknames-blacklisted-domains' ↵tusooa
into 'develop' Make checking blacklisted domains and restricted nicknames case-insensitive Closes #2894 and #2888 See merge request pleroma/pleroma!3687
2022-07-10Make lint happyTusooa Zhu
2022-07-10Merge branch 'from/upstream-develop/tusooa/2830-remote-fo-mp' into 'develop'Haelwenn
Pass remote follow avatar into media proxy Closes #2830 See merge request pleroma/pleroma!3690
2022-07-10Pass remote follow avatar into media proxyTusooa Zhu
2022-07-06Make validation functions for restricted nicknames and blacklisted domains; ↵Sean King
do restricted nickname validation in LDAP account registration
2022-07-05Make checking blacklisted domains and restricted nicknames case-insenstiveSean King
2022-07-05Merge branch 'develop' of https://git.pleroma.social/pleroma/pleroma into ↵Ilja
fine_grained_moderation_privileges
2022-07-03Merge branch 'image_description_from_exif_data' into 'develop'Haelwenn
Use EXIF data of image for image description See merge request pleroma/pleroma!3535
2022-07-03Merge branch 'bugfix/mime-validation-no-list' into 'develop'Haelwenn
Bugfix: Validate mediaType only by it's format See merge request pleroma/pleroma!3597
2022-07-03Merge branch 'from/upstream-develop/tusooa/server-announcements' into 'develop'Haelwenn
Server announcements (1st pass) See merge request pleroma/pleroma!3643
2022-07-02Rename pipelines and add forgotten tagsIlja
I renamed some tags before, but forgot to rename the pipelines I also had some tags which I forgot to add to the config, description, etc. These have now been done/added
2022-07-02Fix typo'sIlja
priviledge |-> privilege
2022-07-01Descriptions from exif data with only whitespeces are considered emptyIlja
I noticed that pictures taken with Ubuntu-Touch have whitespace in one of the fields This should just be ignored imo
2022-07-01update moduledocIlja
2022-07-01Better way of getting keysIlja
I used keyword_list[:key], but if the key doesn't exist, it will return nil. I actually expect a list and further down the code I use that list. I believe the key should always be present, but in case it's not, it's better to return an empty list instead of nil. That way the code wont fail further down the line.
2022-07-01Add deprecation warningsIlja
2022-07-01Rename the Exiftool moduleIlja
No migrations or checks yet
2022-07-01Rename the new moduleIlja
2022-07-01Use EXIF data of image to prefill image descriptionIlja
During attachment upload Pleroma returns a "description" field. Pleroma-fe has an MR to use that to pre-fill the image description field, <https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1399> * This MR allows Pleroma to read the EXIF data during upload and return the description to the FE * If a description is already present (e.g. because a previous module added it), it will use that * Otherwise it will read from the EXIF data. First it will check -ImageDescription, if that's empty, it will check -iptc:Caption-Abstract * If no description is found, it will simply return nil, just like before * When people set up a new instance, they will be asked if they want to read metadata and this module will be activated if so This was taken from an MR i did on Pleroma and isn't finished yet.
2022-07-01Rename privilege tagsIlja
I first focussed on getting things working Now that they do and we know what tags there are, I put some thought in providing better names I use the form <what_it_controls>_<what_it_allows_you_to_do> :statuses_read => :messages_read :status_delete => :messages_delete :user_read => :users_read :user_deletion => :users_delete :user_activation => :users_manage_activation_state :user_invite => :users_manage_invites :user_tag => :users_manage_tags :user_credentials => :users_manage_credentials :report_handle => :reports_manage_reports :emoji_management => :emoji_manage_emoji
2022-06-21Add nodes and privileges to nodeinfoIlja
I didn't add it to /api/v1/instance I was wondering if I should, but since it e.g. also didn't show staff, it felt better not to
2022-06-21Show privileges to FEIlja
I added an extra key We already had is_admin and is_moderator, now we have an extra privileges key
2022-06-21Add deactivated status for privileged usersIlja
Deactivated users are only visible to users privileged with :user_activation since fc317f3b17 Here we also make sure the users who are deactivated get the status deactivated for users who are allowed to see these users
2022-06-21report notifications for privileged usersIlja
Instead of `Pleroma.User.all_superusers()` we now use `Pleroma.User.all_superusers(:report_handle)` I also changed it for sending emails, but there were no tests.
2022-06-21Add Pleroma.User.all_users_with_privilege/1Ilja
This should eventually replace the Pleroma.User.all_superusers/0 function * I added a new param `is_privileged` in User.query * Now we can fetch all users with a specified privilege
2022-06-21Remove function superuser?Ilja
Everything now happens with privileged?/2
2022-06-21Hide pleroma:report for non-privileged usersIlja
Before we deleted the notifications, but that was a side effect and didn't always trigger any more. Now we just hide them when an unprivileged user asks them.
2022-06-21Revert "Delete report notifs when demoting from superuser"Ilja
This reverts commit 89667189b840fc79d85336739e6b2512684d7be0 and cdc5bbe8369d4fc66d642bb3e845a237d11e34d7. This is a side effect when changing user role. The goal was to not have report notifications when someone isn't admin or moderator any more. But this won't be triggered when we change the privilege tags for a role, so we can't use this sollution any more. There was another solution to filter out report notifications during fetch. It wasn't merged because this seemed 'cleaner' at the time, but now it seems the better sollution. I'll add it in the next commit.
2022-06-21User.visible_for/2Ilja
According to the tests, this was only used for unconfirmed accounts. So this just needed to be restricted to users with privilege :user_activation
2022-06-21Validator for deleting statusses is now done with priviledge instead of ↵Ilja
superuser
2022-06-21delete statusses is now privileged by :status_deleteIlja
Instead of superusers, you now need a role with privilige :status_delete to delete other users statusses I also cleaned up some other stuff I saw
2022-06-21Add Pleroma.User.privileged?/2Ilja
This should eventually replace Pleroma.User.superuser?/1
2022-06-21Add last priviligesIlja
I still had three endpoints I didn't really know what to do with them. I added them under separate tags * :instance_delete * :moderation_log_read * :stats_read I also checked and these are the last changes done by MR https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3480/diffs this is trying to fix
2022-06-21Add privilige :emoji_managementIlja
2022-06-21Add privilige :status_deleteIlja
It also allows to update a message, so it's not just deleting. I need a better name...
2022-06-21last off :statuses_readIlja
From the endpoints left to do, I believe these should be under :statuses_read. These should be the last for that privilege for this MR
2022-06-21Add privileges for :user_readIlja
2022-06-21Add privileges for :report_handleIlja
2022-06-21Add privileges for :user_inviteIlja
2022-06-21Add privileges for :user_activationIlja
2022-06-21Add privileges for :user_tagIlja
2022-06-21Remove privileged_staffIlja
Everything that was done through this setting, can now be set by giving the proper privileges to the roles.
2022-06-21Add priviledges for :statuses_readIlja
This was the last in :require_privileged_staff. I'll remove that in the next commit
2022-06-21Add priviledges for :user_credentialsIlja
I only moved the ones from the :require_privileged_staff block for now
2022-06-21Add privilege :user_deletionIlja
2022-06-21Add new setting and Plug to allow for privilege settings for staffIlja
2022-05-31hackney adapter helper & reverse proxy client: enable TLSv1.3Pierre-Louis Bonicoli
The list of TLS versions was added by 8bd2b6eb138ace3408a03c78ecc339fc35b19f10 when hackney version was pinned to 1.15.2. Later hackney version was upgraded (166455c88441b22455d996ed528ed4804514a3c0) but the list of TLS versions wasn't removed. From the hackney point of view, this list has been replaced by the OTP defaults since 0.16.0 (734694ea4e24f267864c459a2f050e943adc6694). It looks like the same issue already occurred before: 0cb7b0ea8477bdd7af2e5e9071843be5b8623dff. A way to test this issue (where example.com is an ActivityPub site which uses TLSv1.3 only): $ PLEROMA_CONFIG_PATH=/path/to/config.exs pleroma start_iex Erlang/OTP 22 [erts-10.7.2.16] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [hipe] Erlang/OTP 22 [erts-10.7.2.16] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [hipe] Interactive Elixir (1.10.4) - press Ctrl+C to exit (type h() ENTER for help) iex(pleroma@127.0.0.1)2> Pleroma.Object.Fetcher.fetch_and_contain_remote_object_from_id("https://example.com/@/Nick/") {:error, {:tls_alert, {:protocol_version, 'TLS client: In state hello received SERVER ALERT: Fatal - Protocol Version\n'}}} With this patch, the output is the expected one: iex(pleroma@127.0.0.1)3> Pleroma.Object.Fetcher.fetch_and_contain_remote_object_from_id("https://example.com/@/Nick/") {:error, {:ok, %{ "@context" => [ "https://www.w3.org/ns/activitystreams", "https://w3id.org/security/v1", %{ "Emoji" => "toot:Emoji", "Hashtag" => "as:Hashtag", "atomUri" => "ostatus:atomUri", "conversation" => "ostatus:conversation", "featured" => "toot:featured", "focalPoint" => %{"@container" => "@list", "@id" => "toot:focalPoint"}, "inReplyToAtomUri" => "ostatus:inReplyToAtomUri", "manuallyApprovesFollowers" => "as:manuallyApprovesFollowers", "movedTo" => "as:movedTo", "ostatus" => "http://ostatus.org#", "sensitive" => "as:sensitive", "toot" => "http://joinmastodon.org/ns#" } ], "endpoints" => %{"sharedInbox" => "https://example.com/inbox"}, "followers" => "https://example.com/@/Nick/followers", "following" => nil, "icon" => %{ "type" => "Image", "url" => "https://example.com/static/media/[...].png" }, "id" => "https://example.com/@/Nick/", "inbox" => "https://example.com/@/Nick/inbox", "liked" => nil, "name" => "Nick", "outbox" => "https://example.com/@/Nick/outbox", "preferredUsername" => "Nick", "publicKey" => %{ "id" => "https://example.com/@/Nick/#main-key", "owner" => "https://example.com/@/Nick/", "publicKeyPem" => "[...] }, "summary" => "", "type" => "Person", "url" => "https://example.com/@/Nick/" }} A way to test the reverse proxy bits of this issue (where example.com allows TLSv1.3 only): iex(pleroma@127.0.0.1)1> Pleroma.ReverseProxy.Client.Hackney.request("GET", "https://example.com", [], []) {:error, {:tls_alert, {:protocol_version, 'TLS client: In state hello received SERVER ALERT: Fatal - Protocol Version\n'}}}
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-25 04:13:15 +0000