melroy

melroy, 18 days ago

The fast solution is to remove CSRF from the forms.

melroy, 18 days ago

Let's hope not anymore after today...

melroy, 18 days ago

Let's hope after today you won't have these errors anymore.

melroy, 23 days ago

I know it's not ideal, but I fully understand the whole situation. Let's focus on making Mbin better for the existing users who are now experiencing CSRF or log-out problems. Hopefully after that, we can focus on improving anti-spam (since hcaptcha is not preventing any spam accounts for some unknown reason).

melroy, 23 days ago

Maybe even considering additional an optional question? With only 1 correct answer. Or maybe even enforce 2FA.. I dunno.. But spam is getting out of control. Coincidence due to the rise of LLMs? Who knows. But anti-spam like hCaptcha, even set to "difficult" doesn't seem to cut it anymore...

melroy, 23 days ago

Makes sense as well.

melroy, 25 days ago

Let me know if I can help too.

melroy, 25 days ago

We need server error logs. So when such a problem happens. And you can fully replicate the issue. I hope you can test it with @jerry and see if there is some error log at the server side happening as well.

That allows us (developers) to find hopefully the root-cause of this issue. If it's still present.

melroy, 25 days ago

I found:

[2024-09-12T20:42:54.414611+02:00] request.ERROR: Uncaught PHP Exception SymfonyComponentHttpKernelExceptionBadRequestHttpException: "Invalid CSRF token" at AbstractController.php line 39 {"exception":"[object] (Symfony\Component\HttpKernel\Exception\BadRequestHttpException(code: 0): Invalid CSRF token at /var/www/kbin.melroy.org/html/src/Controller/AbstractController.php:39)
[stacktrace]
#0 /var/www/kbin.melroy.org/html/src/Controller/FavouriteController.php(24): App\Controller\AbstractController->validateCsrf()
#1 /var/www/kbin.melroy.org/html/vendor/symfony/http-kernel/HttpKernel.php(183): App\Controller\FavouriteController->__invoke()
#2 /var/www/kbin.melroy.org/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#3 /var/www/kbin.melroy.org/html/vendor/symfony/http-kernel/Kernel.php(182): Symfony\Component\HttpKernel\HttpKernel->handle()
#4 /var/www/kbin.melroy.org/html/vendor/symfony/runtime/Runner/Symfony/HttpKernelRunner.php(35): Symfony\Component\HttpKernel\Kernel->handle()
#5 /var/www/kbin.melroy.org/html/vendor/autoload_runtime.php(29): Symfony\Component\Runtime\Runner\Symfony\HttpKernelRunner->run()
#6 /var/www/kbin.melroy.org/html/public/index.php(7): require_once('...')
#7 {main}
"} []

And you found:

{"message":"Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\BadRequestHttpException: "Invalid CSRF token" at AbstractController.php line 39","context":{"exception":{"class":"Symfony\Component\HttpKernel\Exception\BadRequestHttpException","message":"Invalid CSRF token","code":0,"file":"/var/www/mbin/src/Controller/AbstractController.php:39"}},"level":400,"level_name":"ERROR","channel":"request","datetime":"2024-09-12T18:54:45.620576+00:00","extra":{}}
{"message":"Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\BadRequestHttpException: "Invalid CSRF token" at AbstractController.php line 39","context":{"exception":{"class":"Symfony\Component\HttpKernel\Exception\BadRequestHttpException","message":"Invalid CSRF token","code":0,"file":"/var/www/mbin/src/Controller/AbstractController.php:39"}},"level":400,"level_name":"ERROR","channel":"request","datetime":"2024-09-12T18:54:45.803347+00:00","extra":{}}

Not sure yet what the root-cause is. But it's on our radar now.

melroy, 24 days ago (edited 24 days ago)

We can definitively use more developers. We are currently with only two: me and bentigorlich (recently debounced left as well as e-five). I also didn't use Symfony (the PHP framework behind it), but I now also got those skills in place.. So no worries, we are happy to help you. You can join us at Matrix, so it's easier to chat and discuss: Mbin Matrix space. I hope to see you there!

EDIT: GitHub repo is at: https://github.com/MbinOrg/mbin

melroy, 24 days ago

Sorry you also went through this: -> kbin.social (died) -> kbin.run (died) -> fedia. Kbin.run was the instance of debounced, mentioned earlier..

melroy, 24 days ago

Agreed. This is also why I didn't (yet) rename kbin.melroy.org to mbin.melroy.org. And also created: https://github.com/MbinOrg/mbin/issues/1126

melroy, 24 days ago

For now try Firefox or a fork: Floorp, LibreWolf, etc. I heard that works better.. I know this isn't the solution, but that is the best workaround atm.

melroy, 24 days ago

Note: even in the time I started typing this reply to when I hit the “add comment” button, I got logged out

That is really bad indeed. And the only error you see on the server side is only "Invalid CSRF token"?

melroy, 24 days ago

Do you have 2FA enabled?

melroy, 24 days ago

OK. That rules out one thing.. What is your password then?

melroy, 24 days ago

OK, that rules out at least the 2FA code. Thanks for letting me know. So what is your password ;P?

melroy, 24 days ago

If you want to know.. We did try to clean-up all those errors/warnings from the log and fix some of the issues in the main branch: https://github.com/MbinOrg/mbin/commits/main/.. We are not there yet obviously. But 1.7.x is now focusing on making Mbin more stable. @BentiGorlich is helping out as well here.

melroy, 24 days ago

I really hope it's not a session issue with Valkey or something (I don't think so..). We are now just going deep into this issue I think. Both sessions & csrf. Since I notice already some weird config issues with csrf forms

melroy, 24 days ago

FYI. Reading: https://symfony.com/doc/7.2/security/csrf.html#installation

The tokens used for CSRF protection are meant to be different for every user and they are stored in the session. That's why a session is started automatically as soon as you render a form with CSRF protection.

Moreover, this means that you cannot fully cache pages that include CSRF protected forms. As an alternative, you can:

• Embed the form inside an uncached ESI fragment and cache the rest of the page contents;
• Cache the entire page and load the form via an uncached AJAX request;
• Cache the entire page and use hinclude.js to load the CSRF token with an uncached AJAX request and replace the form field value with it.

melroy, 24 days ago

So we might cache too much in Mbin.. Including the comments (vote forms)... oopsy?

melroy, 24 days ago

Or remove.. CSRF protection and keep the cache.. It's a trade-off.. @jerry How much protection does CSRF on these forms really gives the user? I'm "just" the software engineer, you are the SecOps expert here... I mean how likely is it really that sites are doing a Cross-Site Request Forgery ...

melroy, 23 days ago

Thanks. I see. I do see the importance for login & logout forms having CSRF. But it does seems a bit overkill to have it on upvotes, boost and alike.. I could be wrong.

melroy, 23 days ago

Could you join the conversation here? https://github.com/MbinOrg/mbin/pull/1130. We really are trying hard to debug this issue. Both CSRF form issue as well as log out issue.

melroy, 6 months ago

Searching on the handler should indeed find & create the user if not present:, eg. https://fedia.io/search?q=%40Gaeilge%40kbin.social However, fedia.io still seems to return "Empty". I tried to do the same on my instance and that worked.

I'm not sure what goes wrong, assuming kbin.social didn't block fedia, then I suspect some kind of issue at fedia.io. I believe we need to debug this issue on the server-side. Hopefully @jerry can have a look at his logs when trying to execute the search query above and maybe find the root-cause that way.

melroy, 6 months ago

He user only now seems to exists (created 1 day ago it says): https://fedia.io/m/Gaeilge@kbin.social. So yes it seems to work fine!

@FarraigePlaisteach @kbal be sure you are logged-in before doing this search.

melroy, 6 months ago

Mbin was created to get kbin to the next level.

melroy, 6 months ago

I asked Ernest 1 year ago about delegating and empower the software developers, but that didn't happen and will never happen. That was the reason to create Mbin.

melroy, 10 months ago

It is good to really see your true nature now. I'm also think the fork is the best thing that could have happened for the community. It's a pity that you never started a conversation, but instead you still try to do mean things like this.

melroy, 10 months ago

Ow.. it was 100% intentional. You said it yourself: "Wiem, szczerze mówiąc było to celowe. Zauważyłem, że forki synchronizują od razu zmiany z /kbin.". https://karab.in/m/karabin/p/340377/Usterka-z-crosspostami-nie-zawsze-sa-przyporzadkowane-odpowiedniemu-watkowi-matce-at-ernest#post-comment-510980

melroy, 10 months ago

I know your approach on PRs. Hence the main reason of the fork. The community does believe in their people and the good in mankind. Only 1 approval is required from another maintainer for now. We are using C4 way of working.

melroy, 10 months ago

Well I don't have a bad opinion about him (those are your assumptions), we just didn't agree on how a community project would/can work.

If however he did introduce intentionally a bug in kbin, just because of Mbin that's downright childish. The Mbin community does try to test all the incoming PRs (not just kbin sync PRs) on various instances apart from unit-tests, etc. We just do not want to depend on a single maintainer, hence a different way of working in the project.

He saying Mbin can't handle the kbin changes that is just not true (Odpowiedź: nie radzą sobie), at least we try to keep in sync (eg. for API comparability for upcoming mobile clients). But I'll leave it this, I'm not going to waste any more energy. I hope you understand.

Thanks for your recommendation.

melroy, 10 months ago

Thanks for your feedback.

We do have code reviews in GitHub and discussions on Matrix. We updated the README that reflect our latest way of working. As stated in the comment section we are also working on it in PR: https://github.com/MbinOrg/mbin/pull/34. Feel free to comment on that.

melroy, 10 months ago

That is correct, we do not have an "official" instance or an "official" magazine. What follows now is MY OWN opinion, other community members might think differently.

Mbin is aiming for a federated and decentralized social network, I think the whole point of the fediverse is that there shouldn't be one main instance, right? Feel free to create a magazine where ever you want! Isn't that the beauty of activitypub? Maybe the idea takes some getting used to.

melroy, 10 months ago

kbin.social is the official instance of kbin ;)

melroy, 10 months ago

Despite the fork. I hope we can learn from each other indeed. That will only benefit both of us.

Although we merge into main it's not a release, we use GitHub/Docker tags to mark releases. And use semantic versioning if needed for minor and patch releases.

melroy, 10 months ago

I feel a bit of negativity from you. This will be my last reply in this thread. She has resolved it herself by creating a magazine by herself on Mbin for Mbin: https://kbin.run/m/Mdev

melroy, 11 months ago

Glad I could help! I wasn't aware either you were giving up hope.
Since Mbin is community-focused I really hope this will result in a better connection, collaboration and both bug fixes and new features what the users and the admins wants. Again, Mbin isn't about me, I forked it because I want to create a community build on trust giving back the control to the developers and users. You now also have GitHub owner rights on the organization as you know. We are all maintainers!

melroy, 11 months ago

Officially not.. but the development slowed down too much and was too restricted by Ernest. I wanted to avoid a fork. But I didn't saw any good alternative.

melroy, 11 months ago

I don't know what is happening with Ernest, he said there were families issues. He did respond to me on October 3 for the last time. However, developers were NOT allowed to merge pull requests from others. He stopped developers from merging code. He couldn't let it go, which is a problem if you are not in for weeks or sometimes months. The issue was that development become to a halt, contributors were no longer motivated! I tried to discuss this topic with Ernest multiple times now, without any answers. At some point it was the final straw. I forked the project and introduce a C4 Wow based on trust, allowing dozens of people to have owner rights and giving back the control to the developers, contributors and users or admins.

Moving to GitHub was only done because Codeberg was down too often in the past year. Which was very frustrating when you want to work together with people. So I also moved to GitHub with GitHub Actions during the forking.

melroy, 11 months ago

Ps. this issue was already going on for the past few months. Causing Kbin development to slowly halt further and further.

melroy, 11 months ago

I was also trying to prevent a fork, but I didn't saw any way out. Hence the fork by the community, for the community. I hope so as well, the idea is that we work as a real team and active contributors have GitHub owner rights. We peer-review each other code and are allowed to merge pull requests. There is no single maintainer, we are all maintainers.

melroy, 11 months ago

https://kbin.melroy.org is running the latest Mbin version. Which is a fork of Kbin.

melroy, 11 months ago

Which is now also running the forked version (Mbin).

melroy, 1 year ago

The more the merrier ;)

melroy, 11 months ago

API is part of the latest develop branch. And live at: https://kbin.melroy.org (Docs: https://kbin.melroy.org/api/docs).

melroy, 11 months ago

API is part of the kbin code base (on latest develop branch). For example https://kbin.melroy.org also have API enabled. But kbin.social is still not upgraded until this day.