feature: add ability to repost starred items to a feed - #2200
Conversation
|
@Grotax I would be interested in having your inputs |
| * @NoCSRFRequired | ||
| * @PublicPage | ||
| * | ||
| * @param string $name | ||
| * @return array|mixed|\OCP\AppFramework\Http\JSONResponse | ||
| */ | ||
| public function starred($userId) |
There was a problem hiding this comment.
So if you can guess a user ID you can read all their starred items?
There was a problem hiding this comment.
Yes, I was wondering if a token is needed but decided to go with a true, public feed. Do you feel it can bring too many security risks or confusion?
There was a problem hiding this comment.
Personally, I wouldn't want everyone on the Internet to be able to access my starred items.
For example, you may have subscribed to a medical feed and starred the articles matching your condition to save them for later reading.
Even without guessing the user id (which isn't that hard for many users who use the same everywhere possible), there are NC servers were the usernames are visible are visible to other users or can be found via the Profiles feature.
There was a problem hiding this comment.
Another issue for many feeds if not all is that at least in Germany but probably also in a lot of other States you are not allowed to re-publish the content openly. You would need to ask for permission for each feed/item.
Just because the content is public it doesn't mean that you have the right to publish it.
If you do it publicly it might get detected by content scanners.
There was a problem hiding this comment.
I agree, maybe both should be stated in the user interface:
- the feature will publicly repost contents, there is no authentication layer
- user should have the right to repost articles
Maybe the endpoint should also be denied in robots.txt.
Do you want me to check what's displayed in TinyTinyRSS today or adding those mitigations would be enough?
There was a problem hiding this comment.
Thanks for your answer. Would generating a secret key for the feed be acceptable instead of having full user authentication? It would allow sharing the feed publicly without having to share your own credentials.
There was a problem hiding this comment.
If you do full user authentication you can generate an app password which is mostly the same except would not require the news team to maintain it.
There was a problem hiding this comment.
But if the app password is leaked, it gives full access to the user account right?
So if I share the link to someone, I'm giving full access to my account.
There was a problem hiding this comment.
Yes, but the way you're suggesting the news team needs to maintain it's own authentication mechanism. Which I at the very least refuse to do.
There was a problem hiding this comment.
Thanks, I will then close this draft pull request. My understanding from this discussion is that there is no way to implement a feature that would answer the following need: ability to easily share a feed of stared items, with or without a password, to a tier person that does not necessarily have a NextCloud account.
It is super sad because this feature (having a public RSS feed for favorite items) exist in at least the two biggest alternatives of NextCloud News. Namely: Tiny Tiny RSS and FreshRSS (you can test the feature on their demo servers).
| * A renderer for JSON calls | ||
| * @since 6.0.0 | ||
| */ | ||
| class XMLResponse extends Response { |
There was a problem hiding this comment.
Doesn't nextcloud have one of these already?
There was a problem hiding this comment.
Sadly I could not find one, only a JsonResponse. But I'm new to the codebase so I might have missed it.
There was a problem hiding this comment.
There is none. However, your implementation isn't really an XML response because the XML is already built outside ot the Response class.
https://docs.nextcloud.com/server/stable/developer_manual/basics/controllers.html#creating-custom-responses
How about creating a dedicated AtomResponse and move the FeedIo call into the render function?
// response
class AtomResponse extends Response {
public function __construct($feed) {
$this->addHeader('Content-Type', 'application/atom+xml');
$this->feed = $feed;
}
public function render() : string {
return $this->feedIo->toAtom($this->feed);
}
}
// controller
$response = new AtomResponse($feed);Alternatively you could try the existing DataDisplayResponse, but I'm not sure if the Content-Disposition header in there would interfere.
|
Yes I will check, I currently don't have much time due to work. But once I have more I will get more active again 😊 |
4 participants
Summary
Hello! While this is still a draft, I would be interested to have some early feedback and guidance on the feature implementation before committing more energy into it.
This pull request adds the ability to expose starred items as an RSS feed, as it can be done with Tiny Tiny RSS. It can then be used as a simple sharing mechanism. I believe this could be improved a lot, for instance by being able to have repost channels, so you can have multiple RSS feeds, but this implementation is simple and provides a simple MVP.
The main advantage of not using an internal sharing mechanism is that you can push some feed items to some other aggregators. Usage examples:
Screens:
If you star an item:
And subscribe to your own starred RSS feed (of course, this is a bit dumb here):
Then you can see your reposted item.
Would you be interested in this feature being integrated into this project? If yes do you see some core changes that should be applied? Otherwise, I will continue with the checklist below.
Checklist