You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I have somewhat successfully configured Anubis on OpenBSD, using relayd as an http reverse proxy (could add to the wiki if wanted), however I am having some small issues with the misskey instance I am running, specifically the s3 server used for media, which needs to be accessed by the client, but being a different domain the proof of work needs to be done on the s3 server directly.
I know some fix could be to skip the domain entirely at the relayd level or set some regex rule on the policy of anubis, however the solution what would be better in my opinion could be reusing the cookie of the misskey instance for the s3 instance exclusively, I know about the dynamic cookie directive but as far as I can tell it just allow to a cookie to be set for all the domains that are allowed to redirect by anubis, I wonder if it is possible to do this selectively.
Other questions or doubts I have about is, how does anubis works with the fediverse, specially in server to server communication, are the other servers detected as crawlers or any kind of bot, are they subjected to challenges? If so what would be the recommended setting or configuration to bypass the challenge, and in case they are using a default browser user agent what would be the best challenge method to set in order to not give unnecessary load to another instance?
Lastly, I have noticed anubis does not go well with clients that connect directly with the service/instance without any form of OAUTH or browser window, embedded or not, for example, navidrome and clients like feishin or psysonic just don't work at all unless I set up a regex path rule for the api endpoints. However the problem with this approach is that those api endpoints can be now scrapped and they are on an all domains level, meaning that for example the s3 and the misskey instance are also vulnerable to scrapping on those paths.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Hello, I have somewhat successfully configured Anubis on OpenBSD, using relayd as an http reverse proxy (could add to the wiki if wanted), however I am having some small issues with the misskey instance I am running, specifically the s3 server used for media, which needs to be accessed by the client, but being a different domain the proof of work needs to be done on the s3 server directly.
I know some fix could be to skip the domain entirely at the relayd level or set some regex rule on the policy of anubis, however the solution what would be better in my opinion could be reusing the cookie of the misskey instance for the s3 instance exclusively, I know about the dynamic cookie directive but as far as I can tell it just allow to a cookie to be set for all the domains that are allowed to redirect by anubis, I wonder if it is possible to do this selectively.
Other questions or doubts I have about is, how does anubis works with the fediverse, specially in server to server communication, are the other servers detected as crawlers or any kind of bot, are they subjected to challenges? If so what would be the recommended setting or configuration to bypass the challenge, and in case they are using a default browser user agent what would be the best challenge method to set in order to not give unnecessary load to another instance?
Lastly, I have noticed anubis does not go well with clients that connect directly with the service/instance without any form of OAUTH or browser window, embedded or not, for example, navidrome and clients like feishin or psysonic just don't work at all unless I set up a regex path rule for the api endpoints. However the problem with this approach is that those api endpoints can be now scrapped and they are on an all domains level, meaning that for example the s3 and the misskey instance are also vulnerable to scrapping on those paths.
All reactions