2024-07-24 13:27:42 +02:00
|
|
|
// GoToSocial
|
|
|
|
|
// Copyright (C) GoToSocial Authors admin@gotosocial.org
|
|
|
|
|
// SPDX-License-Identifier: AGPL-3.0-or-later
|
|
|
|
|
//
|
|
|
|
|
// This program is free software: you can redistribute it and/or modify
|
|
|
|
|
// it under the terms of the GNU Affero General Public License as published by
|
|
|
|
|
// the Free Software Foundation, either version 3 of the License, or
|
|
|
|
|
// (at your option) any later version.
|
|
|
|
|
//
|
|
|
|
|
// This program is distributed in the hope that it will be useful,
|
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
// GNU Affero General Public License for more details.
|
|
|
|
|
//
|
|
|
|
|
// You should have received a copy of the GNU Affero General Public License
|
|
|
|
|
// along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
|
|
package dereferencing
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"context"
|
2024-09-16 14:08:42 +02:00
|
|
|
"errors"
|
2024-07-26 12:04:28 +02:00
|
|
|
"net/url"
|
2024-09-16 14:08:42 +02:00
|
|
|
"time"
|
2024-07-24 13:27:42 +02:00
|
|
|
|
2025-04-26 15:34:10 +02:00
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/ap"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/db"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/gtscontext"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/gtserror"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/gtsmodel"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/id"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/log"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/uris"
|
|
|
|
|
"code.superseriousbusiness.org/gotosocial/internal/util"
|
2024-07-24 13:27:42 +02:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
// isPermittedStatus returns whether the given status
|
|
|
|
|
// is permitted to be stored on this instance, checking:
|
|
|
|
|
//
|
|
|
|
|
// - author is not suspended
|
|
|
|
|
// - status passes visibility checks
|
|
|
|
|
// - status passes interaction policy checks
|
|
|
|
|
//
|
|
|
|
|
// If status is not permitted to be stored, the function
|
|
|
|
|
// will clean up after itself by removing the status.
|
|
|
|
|
//
|
|
|
|
|
// If status is a reply or a boost, and the author of
|
|
|
|
|
// the given status is only permitted to reply or boost
|
|
|
|
|
// pending approval, then "PendingApproval" will be set
|
|
|
|
|
// to "true" on status. Callers should check this
|
|
|
|
|
// and handle it as appropriate.
|
2024-09-16 14:08:42 +02:00
|
|
|
//
|
|
|
|
|
// If status is a reply that is not permitted based on
|
|
|
|
|
// interaction policies, or status replies to a status
|
|
|
|
|
// that's been Rejected before (ie., it has a rejected
|
|
|
|
|
// InteractionRequest stored in the db) then the reply
|
|
|
|
|
// will also be rejected, and a pre-rejected interaction
|
|
|
|
|
// request will be stored for it before doing cleanup,
|
|
|
|
|
// if one didn't already exist.
|
2024-07-24 13:27:42 +02:00
|
|
|
func (d *Dereferencer) isPermittedStatus(
|
|
|
|
|
ctx context.Context,
|
|
|
|
|
requestUser string,
|
|
|
|
|
existing *gtsmodel.Status,
|
|
|
|
|
status *gtsmodel.Status,
|
2024-12-05 13:35:07 +00:00
|
|
|
isNew bool,
|
2024-07-24 13:27:42 +02:00
|
|
|
) (
|
2024-07-27 09:09:02 +00:00
|
|
|
permitted bool, // is permitted?
|
|
|
|
|
err error,
|
2024-07-24 13:27:42 +02:00
|
|
|
) {
|
2024-07-27 09:09:02 +00:00
|
|
|
switch {
|
|
|
|
|
case status.Account.IsSuspended():
|
|
|
|
|
// we shouldn't reach this point, log to poke devs to investigate.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
log.Warnf(ctx, "should not have reached here, author suspended: %s", status.AccountURI)
|
2024-07-27 09:09:02 +00:00
|
|
|
permitted = false
|
|
|
|
|
|
2024-09-16 14:08:42 +02:00
|
|
|
case status.InReplyToURI != "":
|
2024-07-27 09:09:02 +00:00
|
|
|
// Status is a reply, check permissivity.
|
|
|
|
|
permitted, err = d.isPermittedReply(ctx,
|
2024-07-24 13:27:42 +02:00
|
|
|
requestUser,
|
|
|
|
|
status,
|
|
|
|
|
)
|
2024-07-27 09:09:02 +00:00
|
|
|
if err != nil {
|
|
|
|
|
return false, gtserror.Newf("error checking reply permissivity: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case status.BoostOf != nil:
|
|
|
|
|
// Status is a boost, check permissivity.
|
|
|
|
|
permitted, err = d.isPermittedBoost(ctx,
|
2024-07-24 13:27:42 +02:00
|
|
|
requestUser,
|
|
|
|
|
status,
|
|
|
|
|
)
|
2024-07-27 09:09:02 +00:00
|
|
|
if err != nil {
|
|
|
|
|
return false, gtserror.Newf("error checking boost permissivity: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
// In all other cases
|
|
|
|
|
// permit this status.
|
|
|
|
|
permitted = true
|
2024-07-24 13:27:42 +02:00
|
|
|
}
|
|
|
|
|
|
2024-12-05 13:35:07 +00:00
|
|
|
if !permitted && !isNew {
|
2024-07-27 09:09:02 +00:00
|
|
|
log.Infof(ctx, "deleting unpermitted: %s", existing.URI)
|
|
|
|
|
|
|
|
|
|
// Delete existing status from database as it's no longer permitted.
|
|
|
|
|
if err := d.state.DB.DeleteStatusByID(ctx, existing.ID); err != nil {
|
|
|
|
|
log.Errorf(ctx, "error deleting %s after permissivity fail: %v", existing.URI, err)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return
|
2024-07-24 13:27:42 +02:00
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// isPermittedReply checks whether the given status
|
|
|
|
|
// is a permitted reply to its referenced inReplyTo.
|
2024-07-24 13:27:42 +02:00
|
|
|
func (d *Dereferencer) isPermittedReply(
|
|
|
|
|
ctx context.Context,
|
|
|
|
|
requestUser string,
|
2024-10-08 10:51:13 +02:00
|
|
|
reply *gtsmodel.Status,
|
2024-07-24 13:27:42 +02:00
|
|
|
) (bool, error) {
|
2024-12-05 13:35:07 +00:00
|
|
|
|
2024-09-16 14:08:42 +02:00
|
|
|
var (
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
replyURI = reply.URI // Definitely set.
|
|
|
|
|
|
|
|
|
|
parentURI = reply.InReplyToURI // Definitely set.
|
|
|
|
|
parent = reply.InReplyTo // Might not be set.
|
|
|
|
|
|
2025-02-19 18:09:54 +01:00
|
|
|
approvedByURI = reply.ApprovedByURI // Might not be set.
|
2024-09-16 14:08:42 +02:00
|
|
|
)
|
|
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
// Check if we have a stored interaction request for parent status.
|
|
|
|
|
parentReq, err := d.state.DB.GetInteractionRequestByInteractionURI(
|
2024-09-16 14:08:42 +02:00
|
|
|
gtscontext.SetBarebones(ctx),
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
parentURI,
|
2024-09-16 14:08:42 +02:00
|
|
|
)
|
|
|
|
|
if err != nil && !errors.Is(err, db.ErrNoEntries) {
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
return false, gtserror.Newf("db error getting interaction request: %w", err)
|
2024-09-16 14:08:42 +02:00
|
|
|
}
|
|
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
// Check if we have a stored interaction request for this reply.
|
|
|
|
|
thisReq, err := d.state.DB.GetInteractionRequestByInteractionURI(
|
2024-09-16 14:08:42 +02:00
|
|
|
gtscontext.SetBarebones(ctx),
|
2024-10-08 10:51:13 +02:00
|
|
|
replyURI,
|
2024-09-16 14:08:42 +02:00
|
|
|
)
|
|
|
|
|
if err != nil && !errors.Is(err, db.ErrNoEntries) {
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
return false, gtserror.Newf("db error getting interaction request: %w", err)
|
2024-09-16 14:08:42 +02:00
|
|
|
}
|
|
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
parentRejected := (parentReq != nil && parentReq.IsRejected())
|
|
|
|
|
thisRejected := (thisReq != nil && thisReq.IsRejected())
|
|
|
|
|
|
|
|
|
|
if parentRejected {
|
|
|
|
|
// If this status's parent was rejected,
|
|
|
|
|
// implicitly this reply should be too;
|
|
|
|
|
// there's nothing more to check here.
|
2024-12-05 13:35:07 +00:00
|
|
|
return false, d.unpermittedByParent(ctx,
|
2024-10-08 10:51:13 +02:00
|
|
|
reply,
|
|
|
|
|
thisReq,
|
|
|
|
|
parentReq,
|
|
|
|
|
)
|
|
|
|
|
}
|
2024-09-16 14:08:42 +02:00
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
// Parent wasn't rejected. Check if this
|
|
|
|
|
// reply itself was rejected previously.
|
|
|
|
|
//
|
|
|
|
|
// If it was, and it doesn't now claim to
|
|
|
|
|
// be approved, then we should just reject it
|
|
|
|
|
// again, as nothing's changed since last time.
|
2025-02-19 18:09:54 +01:00
|
|
|
if thisRejected && approvedByURI == "" {
|
2024-12-05 13:35:07 +00:00
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
// Nothing changed,
|
|
|
|
|
// still rejected.
|
2024-09-16 14:08:42 +02:00
|
|
|
return false, nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
// This reply wasn't rejected previously, or
|
|
|
|
|
// it was rejected previously and now claims
|
|
|
|
|
// to be approved. Continue permission checks.
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
if parent == nil {
|
2024-10-08 10:51:13 +02:00
|
|
|
// If we didn't have the replied-to status
|
|
|
|
|
// in our database (yet), we can't check
|
|
|
|
|
// right now if this reply is permitted.
|
|
|
|
|
//
|
|
|
|
|
// For now, just return permitted if reply
|
|
|
|
|
// was not explicitly rejected before; worst-
|
|
|
|
|
// case, the reply stays on the instance for
|
|
|
|
|
// a couple hours until we try to deref it
|
|
|
|
|
// again and realize it should be forbidden.
|
|
|
|
|
return !thisRejected, nil
|
2024-09-16 14:08:42 +02:00
|
|
|
}
|
2024-07-27 09:09:02 +00:00
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
// We have the replied-to status; ensure it's fully populated.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
if err := d.state.DB.PopulateStatus(ctx, parent); err != nil {
|
2024-10-08 10:51:13 +02:00
|
|
|
return false, gtserror.Newf("error populating status %s: %w", reply.ID, err)
|
|
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// Boost wrapper statuses
|
|
|
|
|
// cannot receive replies.
|
|
|
|
|
if parent.BoostOfID != "" {
|
|
|
|
|
log.Warn(ctx, "received reply to boost wrapper status: %s", parent.URI)
|
2024-07-27 09:09:02 +00:00
|
|
|
return false, nil
|
2024-07-24 13:27:42 +02:00
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// If parent is a local status
|
|
|
|
|
// check visibility to replyer.
|
|
|
|
|
if parent.IsLocal() {
|
2024-07-24 13:27:42 +02:00
|
|
|
visible, err := d.visFilter.StatusVisible(ctx,
|
2024-10-08 10:51:13 +02:00
|
|
|
reply.Account,
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
parent,
|
2024-07-24 13:27:42 +02:00
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
err := gtserror.Newf("error checking inReplyTo visibility: %w", err)
|
|
|
|
|
return false, err
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Our status is not visible to the
|
|
|
|
|
// account trying to do the reply.
|
|
|
|
|
if !visible {
|
2024-07-27 09:09:02 +00:00
|
|
|
return false, nil
|
2024-07-24 13:27:42 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
// If this reply claims to be approved,
|
|
|
|
|
// validate this by dereferencing the
|
2025-02-19 18:09:54 +01:00
|
|
|
// approval and checking the return value.
|
2024-10-08 10:51:13 +02:00
|
|
|
// No further checks are required.
|
2025-02-19 18:09:54 +01:00
|
|
|
if approvedByURI != "" {
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
return d.isPermittedByAuthURI(
|
2024-10-08 10:51:13 +02:00
|
|
|
ctx,
|
2025-02-19 18:09:54 +01:00
|
|
|
gtsmodel.InteractionReply,
|
2024-10-08 10:51:13 +02:00
|
|
|
requestUser,
|
|
|
|
|
reply,
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
parent,
|
2024-10-08 10:51:13 +02:00
|
|
|
thisReq,
|
2025-02-19 18:09:54 +01:00
|
|
|
approvedByURI,
|
2024-10-08 10:51:13 +02:00
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Status doesn't claim to be approved.
|
|
|
|
|
// Check interaction policy of inReplyTo
|
2024-10-09 11:02:10 +02:00
|
|
|
// to see what we need to do with it.
|
2024-07-24 13:27:42 +02:00
|
|
|
replyable, err := d.intFilter.StatusReplyable(ctx,
|
2024-10-08 10:51:13 +02:00
|
|
|
reply.Account,
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
parent,
|
2024-07-24 13:27:42 +02:00
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
err := gtserror.Newf("error checking status replyability: %w", err)
|
|
|
|
|
return false, err
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if replyable.Forbidden() {
|
2024-10-08 10:51:13 +02:00
|
|
|
// Reply is not permitted according to policy.
|
2024-09-16 14:08:42 +02:00
|
|
|
//
|
2024-10-08 10:51:13 +02:00
|
|
|
// Either insert a pre-rejected interaction
|
|
|
|
|
// req into the db, or update the existing
|
|
|
|
|
// one, and return. This ensures that replies
|
|
|
|
|
// to this rejected reply also aren't permitted.
|
|
|
|
|
return false, d.rejectedByPolicy(
|
|
|
|
|
ctx,
|
|
|
|
|
reply,
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
parent,
|
2024-10-08 10:51:13 +02:00
|
|
|
thisReq,
|
|
|
|
|
)
|
2024-07-24 13:27:42 +02:00
|
|
|
}
|
|
|
|
|
|
2025-05-13 14:48:11 +00:00
|
|
|
if replyable.AutomaticApproval() &&
|
2024-10-09 11:02:10 +02:00
|
|
|
!replyable.MatchedOnCollection() {
|
|
|
|
|
// Reply is permitted and match was *not* made
|
|
|
|
|
// based on inclusion in a followers/following
|
|
|
|
|
// collection. Just permit the reply full stop
|
2025-02-19 18:09:54 +01:00
|
|
|
// as no explicit approval is necessary.
|
2024-07-26 12:04:28 +02:00
|
|
|
return true, nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-10-09 11:02:10 +02:00
|
|
|
// Reply is either permitted based on inclusion in a
|
|
|
|
|
// followers/following collection, *or* is permitted
|
|
|
|
|
// pending approval, though we know at this point
|
|
|
|
|
// that the status did not include an approvedBy URI.
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
if !parent.IsLocal() {
|
2024-10-09 11:02:10 +02:00
|
|
|
// If the replied-to status is remote, we should just
|
|
|
|
|
// drop this reply at this point, as we can't verify
|
|
|
|
|
// that the remote replied-to account approves it, and
|
|
|
|
|
// we can't verify the presence of a remote account
|
|
|
|
|
// in one of another remote account's collections.
|
|
|
|
|
//
|
2025-02-19 18:09:54 +01:00
|
|
|
// It's possible we'll get an approval from the replied-
|
2024-10-09 11:02:10 +02:00
|
|
|
// to account later, and we can store this reply then.
|
|
|
|
|
return false, nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Replied-to status is ours, so the
|
|
|
|
|
// replied-to account is ours as well.
|
|
|
|
|
|
|
|
|
|
if replyable.MatchedOnCollection() {
|
|
|
|
|
// If permission was granted based on inclusion in
|
|
|
|
|
// a followers/following collection, pre-approve the
|
|
|
|
|
// reply, as we ourselves can validate presence of the
|
|
|
|
|
// replier in the appropriate collection. Pre-approval
|
|
|
|
|
// lets the processor know it should send out an Accept
|
|
|
|
|
// straight away on behalf of the replied-to account.
|
2024-10-08 10:51:13 +02:00
|
|
|
reply.PendingApproval = util.Ptr(true)
|
|
|
|
|
reply.PreApproved = true
|
|
|
|
|
return true, nil
|
|
|
|
|
}
|
2024-07-26 12:04:28 +02:00
|
|
|
|
2024-10-09 11:02:10 +02:00
|
|
|
// Reply just requires approval from the local account
|
|
|
|
|
// it replies to. Set PendingApproval so the processor
|
|
|
|
|
// knows to create a pending interaction request.
|
|
|
|
|
reply.PendingApproval = util.Ptr(true)
|
|
|
|
|
return true, nil
|
2024-10-08 10:51:13 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// unpermittedByParent marks the given reply as rejected
|
|
|
|
|
// based on the fact that its parent was rejected.
|
|
|
|
|
//
|
|
|
|
|
// This will create a rejected interaction request for
|
|
|
|
|
// the status in the db, if one didn't exist already,
|
|
|
|
|
// or update an existing interaction request instead.
|
|
|
|
|
func (d *Dereferencer) unpermittedByParent(
|
|
|
|
|
ctx context.Context,
|
|
|
|
|
reply *gtsmodel.Status,
|
|
|
|
|
thisReq *gtsmodel.InteractionRequest,
|
|
|
|
|
parentReq *gtsmodel.InteractionRequest,
|
|
|
|
|
) error {
|
|
|
|
|
if thisReq != nil && thisReq.IsRejected() {
|
|
|
|
|
// This interaction request is
|
|
|
|
|
// already marked as rejected,
|
|
|
|
|
// there's nothing more to do.
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if thisReq != nil {
|
|
|
|
|
// Before we return, ensure interaction
|
|
|
|
|
// request is marked as rejected.
|
|
|
|
|
thisReq.RejectedAt = time.Now()
|
|
|
|
|
thisReq.AcceptedAt = time.Time{}
|
|
|
|
|
err := d.state.DB.UpdateInteractionRequest(
|
|
|
|
|
ctx,
|
|
|
|
|
thisReq,
|
|
|
|
|
"rejected_at",
|
|
|
|
|
"accepted_at",
|
|
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return gtserror.Newf("db error updating interaction request: %w", err)
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
return nil
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
// We haven't stored a rejected interaction
|
|
|
|
|
// request for this status yet, do it now.
|
|
|
|
|
rejectID := id.NewULID()
|
|
|
|
|
|
|
|
|
|
// To ensure the Reject chain stays coherent,
|
|
|
|
|
// borrow fields from the up-thread rejection.
|
|
|
|
|
// This collapses the chain beyond the first
|
|
|
|
|
// rejected reply and allows us to avoid derefing
|
|
|
|
|
// further replies we already know we don't want.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
inReplyToID := parentReq.TargetStatusID
|
2024-10-08 10:51:13 +02:00
|
|
|
targetAccountID := parentReq.TargetAccountID
|
|
|
|
|
|
|
|
|
|
// As nobody is actually Rejecting the reply
|
|
|
|
|
// directly, but it's an implicit Reject coming
|
|
|
|
|
// from our internal logic, don't bother setting
|
|
|
|
|
// a URI (it's not a required field anyway).
|
|
|
|
|
uri := ""
|
|
|
|
|
|
|
|
|
|
rejection := >smodel.InteractionRequest{
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
ID: rejectID,
|
|
|
|
|
TargetStatusID: inReplyToID,
|
|
|
|
|
TargetAccountID: targetAccountID,
|
|
|
|
|
InteractingAccountID: reply.AccountID,
|
|
|
|
|
InteractionRequestURI: gtsmodel.ForwardCompatibleInteractionRequestURI(reply.URI, gtsmodel.ReplyRequestSuffix),
|
|
|
|
|
InteractionURI: reply.URI,
|
|
|
|
|
InteractionType: gtsmodel.InteractionReply,
|
|
|
|
|
Polite: util.Ptr(false),
|
|
|
|
|
ResponseURI: uri,
|
|
|
|
|
RejectedAt: time.Now(),
|
2024-10-08 10:51:13 +02:00
|
|
|
}
|
|
|
|
|
err := d.state.DB.PutInteractionRequest(ctx, rejection)
|
|
|
|
|
if err != nil && !errors.Is(err, db.ErrAlreadyExists) {
|
|
|
|
|
return gtserror.Newf("db error putting pre-rejected interaction request: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// isPermittedByAuthURI checks whether the given URI
|
2025-02-19 18:09:54 +01:00
|
|
|
// can be dereferenced, and whether it returns either an
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// Accept activity or an authorization object that permits
|
|
|
|
|
// the given reply to the given inReplyTo status.
|
2025-02-19 18:09:54 +01:00
|
|
|
//
|
|
|
|
|
// If yes, then thisReq will be updated to
|
|
|
|
|
// reflect the approval, if it's not nil.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
func (d *Dereferencer) isPermittedByAuthURI(
|
2024-10-08 10:51:13 +02:00
|
|
|
ctx context.Context,
|
2025-02-19 18:09:54 +01:00
|
|
|
interactionType gtsmodel.InteractionType,
|
2024-10-08 10:51:13 +02:00
|
|
|
requestUser string,
|
|
|
|
|
reply *gtsmodel.Status,
|
|
|
|
|
inReplyTo *gtsmodel.Status,
|
|
|
|
|
thisReq *gtsmodel.InteractionRequest,
|
2025-02-19 18:09:54 +01:00
|
|
|
approvedByIRI string,
|
2024-10-08 10:51:13 +02:00
|
|
|
) (bool, error) {
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
permitted, err := d.isValidAuthURI(
|
2024-07-26 12:04:28 +02:00
|
|
|
ctx,
|
2025-02-19 18:09:54 +01:00
|
|
|
interactionType,
|
2024-07-26 12:04:28 +02:00
|
|
|
requestUser,
|
2025-02-19 18:09:54 +01:00
|
|
|
approvedByIRI, // approval iri
|
|
|
|
|
inReplyTo.AccountURI, // actor
|
|
|
|
|
reply.URI, // object
|
|
|
|
|
reply.InReplyToURI, // target
|
2024-10-08 10:51:13 +02:00
|
|
|
)
|
|
|
|
|
if err != nil {
|
2024-07-26 12:04:28 +02:00
|
|
|
// Error dereferencing means we couldn't
|
2025-02-19 18:09:54 +01:00
|
|
|
// get the approval right now or it wasn't
|
2024-07-26 12:04:28 +02:00
|
|
|
// valid, so we shouldn't store this status.
|
2025-02-19 18:09:54 +01:00
|
|
|
err := gtserror.Newf("undereferencable approvedByURI: %w", err)
|
2024-10-08 10:51:13 +02:00
|
|
|
return false, err
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if !permitted {
|
|
|
|
|
// It's a no from
|
|
|
|
|
// us, squirt.
|
2024-07-27 09:09:02 +00:00
|
|
|
return false, nil
|
2024-07-24 13:27:42 +02:00
|
|
|
}
|
|
|
|
|
|
2025-02-19 18:09:54 +01:00
|
|
|
// Reply is permitted by this approval.
|
2024-10-08 10:51:13 +02:00
|
|
|
// If it was previously rejected or
|
|
|
|
|
// pending approval, clear that now.
|
|
|
|
|
reply.PendingApproval = util.Ptr(false)
|
|
|
|
|
if thisReq != nil {
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
thisReq.ResponseURI = approvedByIRI
|
2024-10-08 10:51:13 +02:00
|
|
|
thisReq.AcceptedAt = time.Now()
|
|
|
|
|
thisReq.RejectedAt = time.Time{}
|
|
|
|
|
err := d.state.DB.UpdateInteractionRequest(
|
|
|
|
|
ctx,
|
|
|
|
|
thisReq,
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
"response_uri",
|
2024-10-08 10:51:13 +02:00
|
|
|
"accepted_at",
|
|
|
|
|
"rejected_at",
|
|
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return false, gtserror.Newf("db error updating interaction request: %w", err)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// All good!
|
2024-07-24 13:27:42 +02:00
|
|
|
return true, nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
func (d *Dereferencer) rejectedByPolicy(
|
|
|
|
|
ctx context.Context,
|
|
|
|
|
reply *gtsmodel.Status,
|
|
|
|
|
inReplyTo *gtsmodel.Status,
|
|
|
|
|
thisReq *gtsmodel.InteractionRequest,
|
|
|
|
|
) error {
|
|
|
|
|
var (
|
|
|
|
|
rejectID string
|
|
|
|
|
rejectURI string
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
if thisReq != nil {
|
|
|
|
|
// Reuse existing ID.
|
|
|
|
|
rejectID = thisReq.ID
|
|
|
|
|
} else {
|
|
|
|
|
// Generate new ID.
|
|
|
|
|
rejectID = id.NewULID()
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if inReplyTo.IsLocal() {
|
|
|
|
|
// If this a reply to one of our statuses
|
|
|
|
|
// we should generate a URI for the Reject,
|
|
|
|
|
// else just use an implicit (empty) URI.
|
|
|
|
|
rejectURI = uris.GenerateURIForReject(
|
|
|
|
|
inReplyTo.Account.Username,
|
|
|
|
|
rejectID,
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if thisReq != nil {
|
|
|
|
|
// Before we return, ensure interaction
|
|
|
|
|
// request is marked as rejected.
|
|
|
|
|
thisReq.RejectedAt = time.Now()
|
|
|
|
|
thisReq.AcceptedAt = time.Time{}
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
thisReq.ResponseURI = rejectURI
|
2024-10-08 10:51:13 +02:00
|
|
|
err := d.state.DB.UpdateInteractionRequest(
|
|
|
|
|
ctx,
|
|
|
|
|
thisReq,
|
|
|
|
|
"rejected_at",
|
|
|
|
|
"accepted_at",
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
"response_uri",
|
2024-10-08 10:51:13 +02:00
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return gtserror.Newf("db error updating interaction request: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// We haven't stored a rejected interaction
|
|
|
|
|
// request for this status yet, do it now.
|
|
|
|
|
rejection := >smodel.InteractionRequest{
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
ID: rejectID,
|
|
|
|
|
TargetStatusID: inReplyTo.ID,
|
|
|
|
|
TargetAccountID: inReplyTo.AccountID,
|
|
|
|
|
InteractingAccountID: reply.AccountID,
|
|
|
|
|
InteractionRequestURI: gtsmodel.ForwardCompatibleInteractionRequestURI(reply.URI, gtsmodel.ReplyRequestSuffix),
|
|
|
|
|
InteractionURI: reply.URI,
|
|
|
|
|
InteractionType: gtsmodel.InteractionReply,
|
|
|
|
|
Polite: util.Ptr(false),
|
|
|
|
|
ResponseURI: rejectURI,
|
|
|
|
|
RejectedAt: time.Now(),
|
2024-10-08 10:51:13 +02:00
|
|
|
}
|
|
|
|
|
err := d.state.DB.PutInteractionRequest(ctx, rejection)
|
|
|
|
|
if err != nil && !errors.Is(err, db.ErrAlreadyExists) {
|
|
|
|
|
return gtserror.Newf("db error putting pre-rejected interaction request: %w", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-07-24 13:27:42 +02:00
|
|
|
func (d *Dereferencer) isPermittedBoost(
|
|
|
|
|
ctx context.Context,
|
|
|
|
|
requestUser string,
|
|
|
|
|
status *gtsmodel.Status,
|
|
|
|
|
) (bool, error) {
|
2024-07-27 09:09:02 +00:00
|
|
|
|
|
|
|
|
// Extract boost from status.
|
|
|
|
|
boostOf := status.BoostOf
|
2024-07-24 13:27:42 +02:00
|
|
|
if boostOf.BoostOfID != "" {
|
2024-07-27 09:09:02 +00:00
|
|
|
|
2024-07-24 13:27:42 +02:00
|
|
|
// We do not permit boosts of
|
|
|
|
|
// boost wrapper statuses. (this
|
|
|
|
|
// shouldn't be able to happen).
|
2024-07-27 09:09:02 +00:00
|
|
|
return false, nil
|
2024-07-24 13:27:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Check visibility of local
|
|
|
|
|
// boostOf to boosting account.
|
|
|
|
|
if boostOf.IsLocal() {
|
|
|
|
|
visible, err := d.visFilter.StatusVisible(ctx,
|
|
|
|
|
status.Account,
|
|
|
|
|
boostOf,
|
|
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
err := gtserror.Newf("error checking boostOf visibility: %w", err)
|
|
|
|
|
return false, err
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Our status is not visible to the
|
|
|
|
|
// account trying to do the boost.
|
|
|
|
|
if !visible {
|
2024-07-27 09:09:02 +00:00
|
|
|
return false, nil
|
2024-07-24 13:27:42 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Check interaction policy of boostOf.
|
|
|
|
|
boostable, err := d.intFilter.StatusBoostable(ctx,
|
|
|
|
|
status.Account,
|
|
|
|
|
boostOf,
|
|
|
|
|
)
|
|
|
|
|
if err != nil {
|
|
|
|
|
err := gtserror.Newf("error checking status boostability: %w", err)
|
|
|
|
|
return false, err
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if boostable.Forbidden() {
|
|
|
|
|
// Booster is not permitted
|
|
|
|
|
// to do this interaction.
|
2024-07-27 09:09:02 +00:00
|
|
|
return false, nil
|
2024-07-24 13:27:42 +02:00
|
|
|
}
|
|
|
|
|
|
2025-05-13 14:48:11 +00:00
|
|
|
if boostable.AutomaticApproval() &&
|
2024-07-26 12:04:28 +02:00
|
|
|
!boostable.MatchedOnCollection() {
|
|
|
|
|
// Booster is permitted to do this
|
|
|
|
|
// interaction, and didn't match on
|
|
|
|
|
// a collection so we don't need to
|
|
|
|
|
// do further checking.
|
|
|
|
|
return true, nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Booster is permitted to do this
|
|
|
|
|
// interaction pending approval, or
|
|
|
|
|
// permitted but matched on a collection.
|
|
|
|
|
//
|
|
|
|
|
// Check if we can dereference
|
2025-02-19 18:09:54 +01:00
|
|
|
// an IRI that grants approval.
|
2024-07-26 12:04:28 +02:00
|
|
|
|
|
|
|
|
if status.ApprovedByURI == "" {
|
|
|
|
|
// Status doesn't claim to be approved.
|
|
|
|
|
//
|
|
|
|
|
// For boosts of local statuses that's
|
|
|
|
|
// fine, we can put it in the DB pending
|
|
|
|
|
// approval, and continue processing it.
|
|
|
|
|
//
|
|
|
|
|
// If permission was granted based on a match
|
|
|
|
|
// with a followers or following collection,
|
|
|
|
|
// we can mark it as PreApproved so the processor
|
|
|
|
|
// sends an accept out for it immediately.
|
|
|
|
|
//
|
|
|
|
|
// For boosts of remote statuses, though
|
|
|
|
|
// we should be polite and just drop it.
|
|
|
|
|
if boostOf.IsLocal() {
|
|
|
|
|
status.PendingApproval = util.Ptr(true)
|
|
|
|
|
status.PreApproved = boostable.MatchedOnCollection()
|
|
|
|
|
return true, nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-07-27 09:09:02 +00:00
|
|
|
return false, nil
|
2024-07-24 13:27:42 +02:00
|
|
|
}
|
|
|
|
|
|
2024-07-26 12:04:28 +02:00
|
|
|
// Boost claims to be approved, check
|
2025-02-19 18:09:54 +01:00
|
|
|
// this by dereferencing the approvedBy
|
|
|
|
|
// and inspecting the return value.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
permitted, err := d.isValidAuthURI(
|
2024-07-26 12:04:28 +02:00
|
|
|
ctx,
|
2025-02-19 18:09:54 +01:00
|
|
|
gtsmodel.InteractionAnnounce,
|
2024-07-26 12:04:28 +02:00
|
|
|
requestUser,
|
2025-02-19 18:09:54 +01:00
|
|
|
status.ApprovedByURI, // approval uri
|
|
|
|
|
boostOf.AccountURI, // actor
|
|
|
|
|
status.URI, // object
|
|
|
|
|
status.BoostOfURI, // target
|
2024-10-08 10:51:13 +02:00
|
|
|
)
|
|
|
|
|
if err != nil {
|
2024-07-26 12:04:28 +02:00
|
|
|
// Error dereferencing means we couldn't
|
2025-02-19 18:09:54 +01:00
|
|
|
// get the approval right now or it wasn't
|
2024-07-26 12:04:28 +02:00
|
|
|
// valid, so we shouldn't store this status.
|
2024-10-08 10:51:13 +02:00
|
|
|
err := gtserror.Newf("undereferencable ApprovedByURI: %w", err)
|
|
|
|
|
return false, err
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if !permitted {
|
2024-07-27 09:09:02 +00:00
|
|
|
return false, nil
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Status has been approved.
|
|
|
|
|
status.PendingApproval = util.Ptr(false)
|
2024-07-24 13:27:42 +02:00
|
|
|
return true, nil
|
|
|
|
|
}
|
2024-07-26 12:04:28 +02:00
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// isValidAuthURI dereferences the activitystreams Accept or authorization
|
|
|
|
|
// at the specified IRI, and checks it for validity against the provided
|
|
|
|
|
// expectedActor, expectedObject, and expectedTarget.
|
2024-07-26 12:04:28 +02:00
|
|
|
//
|
2024-10-08 10:51:13 +02:00
|
|
|
// Will return either (true, nil) if everything looked OK, an error
|
|
|
|
|
// if something went wrong internally during deref, or (false, nil)
|
2025-02-19 18:09:54 +01:00
|
|
|
// if the dereferenced Accept/Approval did not meet expectations.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
func (d *Dereferencer) isValidAuthURI(
|
2024-07-26 12:04:28 +02:00
|
|
|
ctx context.Context,
|
2025-02-19 18:09:54 +01:00
|
|
|
interactionType gtsmodel.InteractionType,
|
2024-07-26 12:04:28 +02:00
|
|
|
requestUser string,
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
authIRIStr string, // authorization uri Eg., "https://example.org/users/someone/accepts/01J2736AWWJ3411CPR833F6D03"
|
2025-02-19 18:09:54 +01:00
|
|
|
expectActorURIStr string, // actor Eg., "https://example.org/users/someone"
|
|
|
|
|
expectObjectURIStr string, // object Eg., "https://some.instance.example.org/users/someone_else/statuses/01J27414TWV9F7DC39FN8ABB5R"
|
|
|
|
|
expectTargetURIStr string, // target Eg., "https://example.org/users/someone/statuses/01JM4REQTJ1BZ1R4BPYP1W4R9E"
|
2024-10-08 10:51:13 +02:00
|
|
|
) (bool, error) {
|
|
|
|
|
l := log.
|
|
|
|
|
WithContext(ctx).
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
WithField("authIRI", authIRIStr)
|
2024-10-08 10:51:13 +02:00
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
authIRI, err := url.Parse(authIRIStr)
|
2024-07-26 12:04:28 +02:00
|
|
|
if err != nil {
|
2024-10-08 10:51:13 +02:00
|
|
|
// Real returnable error.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
err := gtserror.Newf("error parsing authIRI: %w", err)
|
2024-10-08 10:51:13 +02:00
|
|
|
return false, err
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
2025-02-19 18:09:54 +01:00
|
|
|
// Don't make calls to the IRI if its
|
|
|
|
|
// domain is blocked, just return false.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
blocked, err := d.state.DB.IsDomainBlocked(ctx, authIRI.Host)
|
2024-10-08 10:51:13 +02:00
|
|
|
if err != nil {
|
|
|
|
|
// Real returnable error.
|
|
|
|
|
err := gtserror.Newf("error checking domain block: %w", err)
|
|
|
|
|
return false, err
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if blocked {
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
l.Info("authIRI host is blocked")
|
2024-10-08 10:51:13 +02:00
|
|
|
return false, nil
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
2024-07-27 09:09:02 +00:00
|
|
|
tsport, err := d.transportController.NewTransportForUsername(ctx, requestUser)
|
2024-07-26 12:04:28 +02:00
|
|
|
if err != nil {
|
2024-10-08 10:51:13 +02:00
|
|
|
// Real returnable error.
|
2024-07-26 12:04:28 +02:00
|
|
|
err := gtserror.Newf("error creating transport: %w", err)
|
2024-10-08 10:51:13 +02:00
|
|
|
return false, err
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// Make the call to the authIRI.
|
2024-10-08 10:51:13 +02:00
|
|
|
// Log any error encountered here but don't
|
|
|
|
|
// return it as it's not *our* error.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
rsp, err := tsport.Dereference(ctx, authIRI)
|
2024-07-26 12:04:28 +02:00
|
|
|
if err != nil {
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
l.Errorf("error dereferencing authIRI: %v", err)
|
2024-10-08 10:51:13 +02:00
|
|
|
return false, nil
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
2025-02-19 18:09:54 +01:00
|
|
|
// Try to parse response as an AP type.
|
|
|
|
|
t, err := ap.DecodeType(ctx, rsp.Body)
|
2024-07-26 12:04:28 +02:00
|
|
|
|
|
|
|
|
// Tidy up rsp body.
|
|
|
|
|
_ = rsp.Body.Close()
|
|
|
|
|
|
|
|
|
|
if err != nil {
|
2025-02-19 18:09:54 +01:00
|
|
|
l.Errorf("error resolving to type: %v", err)
|
2024-10-08 10:51:13 +02:00
|
|
|
return false, err
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
2025-02-19 18:09:54 +01:00
|
|
|
// Extract the URI/ID of the type.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
authID := ap.GetJSONLDId(t)
|
|
|
|
|
authIDStr := authID.String()
|
2024-07-26 12:04:28 +02:00
|
|
|
|
|
|
|
|
// Check whether input URI and final returned URI
|
|
|
|
|
// have changed (i.e. we followed some redirects).
|
|
|
|
|
rspURL := rsp.Request.URL
|
|
|
|
|
rspURLStr := rspURL.String()
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
if rspURLStr != authIRIStr {
|
2025-02-19 18:09:54 +01:00
|
|
|
// If rspURLStr != approvedByIRI, make sure final
|
2024-10-08 10:51:13 +02:00
|
|
|
// response URL is at least on the same host as
|
|
|
|
|
// what we expected (ie., we weren't redirected
|
|
|
|
|
// across domains), and make sure it's the same
|
|
|
|
|
// as the ID of the Accept we were returned.
|
|
|
|
|
switch {
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
case rspURL.Host != authIRI.Host:
|
2024-10-08 10:51:13 +02:00
|
|
|
l.Errorf(
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
"final deref host %s did not match authIRI host",
|
2024-10-08 10:51:13 +02:00
|
|
|
rspURL.Host,
|
|
|
|
|
)
|
|
|
|
|
return false, nil
|
2024-07-26 12:04:28 +02:00
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
case authIDStr != rspURLStr:
|
2024-10-08 10:51:13 +02:00
|
|
|
l.Errorf(
|
2025-02-19 18:09:54 +01:00
|
|
|
"final deref uri %s did not match returned ID %s",
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
rspURLStr, authIDStr,
|
2024-10-08 10:51:13 +02:00
|
|
|
)
|
|
|
|
|
return false, nil
|
|
|
|
|
}
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
// Response is superficially OK,
|
|
|
|
|
// check in more detail now.
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// First try to parse type as Authorization stamp.
|
|
|
|
|
if authable, ok := ap.ToAuthorizationable(t); ok {
|
|
|
|
|
return isValidAuthorization(
|
2025-02-19 18:09:54 +01:00
|
|
|
ctx,
|
|
|
|
|
interactionType,
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
authable,
|
|
|
|
|
authID,
|
2025-02-19 18:09:54 +01:00
|
|
|
expectActorURIStr, // actor
|
|
|
|
|
expectObjectURIStr, // object
|
|
|
|
|
expectTargetURIStr, // target
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Fall back to parsing as a simple Accept.
|
|
|
|
|
if acceptable, ok := ap.ToAcceptable(t); ok {
|
|
|
|
|
return isValidAcceptable(
|
|
|
|
|
ctx,
|
|
|
|
|
acceptable,
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
authID,
|
2025-02-19 18:09:54 +01:00
|
|
|
expectActorURIStr, // actor
|
|
|
|
|
expectObjectURIStr, // object
|
|
|
|
|
expectTargetURIStr, // target
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Type wasn't something we
|
|
|
|
|
// could do anything with!
|
|
|
|
|
l.Errorf(
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
"%T at %s not authorization or accept",
|
|
|
|
|
t, authIRIStr,
|
2025-02-19 18:09:54 +01:00
|
|
|
)
|
|
|
|
|
return false, nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func isValidAcceptable(
|
|
|
|
|
ctx context.Context,
|
|
|
|
|
acceptable ap.Acceptable,
|
|
|
|
|
acceptID *url.URL,
|
|
|
|
|
expectActorURIStr string, // actor Eg., "https://example.org/users/someone"
|
|
|
|
|
expectObjectURIStr string, // object Eg., "https://some.instance.example.org/users/someone_else/statuses/01J27414TWV9F7DC39FN8ABB5R"
|
|
|
|
|
expectTargetURIStr string, // target Eg., "https://example.org/users/someone/statuses/01JM4REQTJ1BZ1R4BPYP1W4R9E"
|
|
|
|
|
) (bool, error) {
|
|
|
|
|
l := log.
|
|
|
|
|
WithContext(ctx).
|
|
|
|
|
WithField("accept", acceptID.String())
|
|
|
|
|
|
2024-07-27 09:09:02 +00:00
|
|
|
// Extract the actor IRI and string from Accept.
|
2024-07-26 12:04:28 +02:00
|
|
|
actorIRIs := ap.GetActorIRIs(acceptable)
|
2024-07-27 09:09:02 +00:00
|
|
|
actorIRI, actorIRIStr := extractIRI(actorIRIs)
|
|
|
|
|
switch {
|
|
|
|
|
case actorIRIStr == "":
|
2024-10-08 10:51:13 +02:00
|
|
|
l.Error("Accept missing actor IRI")
|
|
|
|
|
return false, nil
|
2024-07-26 12:04:28 +02:00
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
// Ensure the Accept Actor is on
|
|
|
|
|
// the instance hosting the Accept.
|
|
|
|
|
case actorIRI.Host != acceptID.Host:
|
|
|
|
|
l.Errorf(
|
|
|
|
|
"actor %s not on the same host as Accept",
|
|
|
|
|
actorIRIStr,
|
2024-07-26 12:04:28 +02:00
|
|
|
)
|
2024-10-08 10:51:13 +02:00
|
|
|
return false, nil
|
2024-07-26 12:04:28 +02:00
|
|
|
|
|
|
|
|
// Ensure the Accept Actor is who we expect
|
|
|
|
|
// it to be, and not someone else trying to
|
|
|
|
|
// do an Accept for an interaction with a
|
|
|
|
|
// statusable they don't own.
|
2024-07-27 09:09:02 +00:00
|
|
|
case actorIRIStr != expectActorURIStr:
|
2024-10-08 10:51:13 +02:00
|
|
|
l.Errorf(
|
|
|
|
|
"actor %s was not the same as expected actor %s",
|
2024-07-27 09:09:02 +00:00
|
|
|
actorIRIStr, expectActorURIStr,
|
2024-07-26 12:04:28 +02:00
|
|
|
)
|
2024-10-08 10:51:13 +02:00
|
|
|
return false, nil
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
2024-07-27 09:09:02 +00:00
|
|
|
// Extract the object IRI string from Accept.
|
|
|
|
|
objectIRIs := ap.GetObjectIRIs(acceptable)
|
|
|
|
|
_, objectIRIStr := extractIRI(objectIRIs)
|
|
|
|
|
switch {
|
|
|
|
|
case objectIRIStr == "":
|
2024-10-08 10:51:13 +02:00
|
|
|
l.Error("missing Accept object IRI")
|
|
|
|
|
return false, nil
|
2024-07-27 09:09:02 +00:00
|
|
|
|
2024-07-26 12:04:28 +02:00
|
|
|
// Ensure the Accept Object is what we expect
|
|
|
|
|
// it to be, ie., it's Accepting the interaction
|
|
|
|
|
// we need it to Accept, and not something else.
|
2024-07-27 09:09:02 +00:00
|
|
|
case objectIRIStr != expectObjectURIStr:
|
2024-10-08 10:51:13 +02:00
|
|
|
l.Errorf(
|
|
|
|
|
"resolved Accept object IRI %s was not the same as expected object %s",
|
2024-07-27 09:09:02 +00:00
|
|
|
objectIRIStr, expectObjectURIStr,
|
2024-07-26 12:04:28 +02:00
|
|
|
)
|
2024-10-08 10:51:13 +02:00
|
|
|
return false, nil
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
|
|
|
|
|
2025-02-19 18:09:54 +01:00
|
|
|
// If there's a Target set then verify it's
|
|
|
|
|
// what we expect it to be, ie., it should point
|
|
|
|
|
// back to the post that's being interacted with.
|
|
|
|
|
targetIRIs := ap.GetTargetIRIs(acceptable)
|
|
|
|
|
_, targetIRIStr := extractIRI(targetIRIs)
|
|
|
|
|
if targetIRIStr != "" && targetIRIStr != expectTargetURIStr {
|
|
|
|
|
l.Errorf(
|
|
|
|
|
"resolved Accept target IRI %s was not the same as expected target %s",
|
|
|
|
|
targetIRIStr, expectTargetURIStr,
|
|
|
|
|
)
|
|
|
|
|
return false, nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Everything looks OK.
|
|
|
|
|
return true, nil
|
|
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
func isValidAuthorization(
|
2025-02-19 18:09:54 +01:00
|
|
|
ctx context.Context,
|
|
|
|
|
interactionType gtsmodel.InteractionType,
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
auth ap.Authorizationable,
|
|
|
|
|
authID *url.URL,
|
2025-02-19 18:09:54 +01:00
|
|
|
expectActorURIStr string, // actor Eg., "https://example.org/users/someone"
|
|
|
|
|
expectObjectURIStr string, // object Eg., "https://some.instance.example.org/users/someone_else/statuses/01J27414TWV9F7DC39FN8ABB5R"
|
|
|
|
|
expectTargetURIStr string, // target Eg., "https://example.org/users/someone/statuses/01JM4REQTJ1BZ1R4BPYP1W4R9E"
|
|
|
|
|
) (bool, error) {
|
|
|
|
|
l := log.
|
|
|
|
|
WithContext(ctx).
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
WithField("auth", authID.String())
|
2025-02-19 18:09:54 +01:00
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// Check that the type of the Authorization
|
2025-02-19 18:09:54 +01:00
|
|
|
// matches the interaction it's approving.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
switch tn := auth.GetTypeName(); {
|
|
|
|
|
case (tn == ap.ObjectLikeAuthorization && interactionType == gtsmodel.InteractionLike),
|
|
|
|
|
(tn == ap.ObjectReplyAuthorization && interactionType == gtsmodel.InteractionReply),
|
|
|
|
|
(tn == ap.ObjectAnnounceAuthorization && interactionType == gtsmodel.InteractionAnnounce):
|
2025-02-19 18:09:54 +01:00
|
|
|
// All good baby!
|
|
|
|
|
default:
|
|
|
|
|
// There's a mismatch.
|
|
|
|
|
l.Errorf(
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
"authorization type %s cannot approve %s",
|
2025-02-19 18:09:54 +01:00
|
|
|
tn, interactionType.String(),
|
|
|
|
|
)
|
|
|
|
|
return false, nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Extract the actor IRI and string from Approval.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
actorIRIs := ap.GetAttributedTo(auth)
|
2025-02-19 18:09:54 +01:00
|
|
|
actorIRI, actorIRIStr := extractIRI(actorIRIs)
|
|
|
|
|
switch {
|
|
|
|
|
case actorIRIStr == "":
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
l.Error("authorization missing attributedTo IRI")
|
2025-02-19 18:09:54 +01:00
|
|
|
return false, nil
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// Ensure the authorization actor is on
|
2025-02-19 18:09:54 +01:00
|
|
|
// the instance hosting the Approval.
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
case actorIRI.Host != authID.Host:
|
2025-02-19 18:09:54 +01:00
|
|
|
l.Errorf(
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
"actor %s not on the same host as authorization",
|
2025-02-19 18:09:54 +01:00
|
|
|
actorIRIStr,
|
|
|
|
|
)
|
|
|
|
|
return false, nil
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// Ensure the auth actor is who we expect
|
2025-02-19 18:09:54 +01:00
|
|
|
// it to be, and not someone else trying to
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// do an auth for an interaction with a
|
2025-02-19 18:09:54 +01:00
|
|
|
// statusable they don't own.
|
|
|
|
|
case actorIRIStr != expectActorURIStr:
|
|
|
|
|
l.Errorf(
|
|
|
|
|
"actor %s was not the same as expected actor %s",
|
|
|
|
|
actorIRIStr, expectActorURIStr,
|
|
|
|
|
)
|
|
|
|
|
return false, nil
|
|
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// Extract the object IRI string from authorization.
|
|
|
|
|
objectIRIs := ap.GetInteractingObject(auth)
|
2025-02-19 18:09:54 +01:00
|
|
|
_, objectIRIStr := extractIRI(objectIRIs)
|
|
|
|
|
switch {
|
|
|
|
|
case objectIRIStr == "":
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
l.Error("missing authorization interactingObject IRI")
|
2025-02-19 18:09:54 +01:00
|
|
|
return false, nil
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// Ensure the authorization object is what we expect
|
2025-02-19 18:09:54 +01:00
|
|
|
// it to be, ie., it's approving the interaction
|
|
|
|
|
// we need it to approve, and not something else.
|
|
|
|
|
case objectIRIStr != expectObjectURIStr:
|
|
|
|
|
l.Errorf(
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
"resolved authorization interactingObject IRI %s was not the same as expected object %s",
|
2025-02-19 18:09:54 +01:00
|
|
|
objectIRIStr, expectObjectURIStr,
|
|
|
|
|
)
|
|
|
|
|
return false, nil
|
|
|
|
|
}
|
|
|
|
|
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
// Ensure the authorization target is what we expect,
|
|
|
|
|
// ie., it should be the status being interacted with.
|
|
|
|
|
targetIRIs := ap.GetInteractionTarget(auth)
|
2025-02-19 18:09:54 +01:00
|
|
|
_, targetIRIStr := extractIRI(targetIRIs)
|
|
|
|
|
if targetIRIStr != "" && targetIRIStr != expectTargetURIStr {
|
|
|
|
|
l.Errorf(
|
[feature] Support new model of interaction flow for forward compat with v0.21.0 (#4394)
~~Still WIP!~~
This PR allows v0.20.0 of GtS to be forward-compatible with the interaction request / authorization flow that will fully replace the current flow in v0.21.0.
Basically, this means we need to recognize LikeRequest, ReplyRequest, and AnnounceRequest, and in response to those requests, deliver either a Reject or an Accept, with the latter pointing towards a LikeAuthorization, ReplyAuthorization, or AnnounceAuthorization, respectively. This can then be used by the remote instance to prove to third parties that the interaction has been accepted by the interactee. These Authorization types need to be dereferencable to third parties, so we need to serve them.
As well as recognizing the above "polite" interaction request types, we also need to still serve appropriate responses to "impolite" interaction request types, where an instance that's unaware of interaction policies tries to interact with a post by sending a reply, like, or boost directly, without wrapping it in a WhateverRequest type.
Doesn't fully close https://codeberg.org/superseriousbusiness/gotosocial/issues/4026 but gets damn near (just gotta update the federating with GtS documentation).
Migrations tested on both Postgres and SQLite.
Co-authored-by: kim <grufwub@gmail.com>
Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4394
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
2025-09-14 15:37:35 +02:00
|
|
|
"resolved authorization interactionTarget IRI %s was not the same as expected target %s",
|
2025-02-19 18:09:54 +01:00
|
|
|
targetIRIStr, expectTargetURIStr,
|
|
|
|
|
)
|
|
|
|
|
return false, nil
|
|
|
|
|
}
|
|
|
|
|
|
2024-10-08 10:51:13 +02:00
|
|
|
// Everything looks OK.
|
|
|
|
|
return true, nil
|
2024-07-26 12:04:28 +02:00
|
|
|
}
|
2024-07-27 09:09:02 +00:00
|
|
|
|
|
|
|
|
// extractIRI is shorthand to extract the first IRI
|
|
|
|
|
// url.URL{} object and serialized form from slice.
|
|
|
|
|
func extractIRI(iris []*url.URL) (*url.URL, string) {
|
|
|
|
|
if len(iris) == 0 {
|
|
|
|
|
return nil, ""
|
|
|
|
|
}
|
|
|
|
|
u := iris[0]
|
|
|
|
|
return u, u.String()
|
|
|
|
|
}
|