I'm getting this weird error when clicking on a notification of someone else posting a topic in a category I'm following.
The link of the notification is:
https://forum.solutioapp.com/-79/payment-process-grant-version#post-1
If I access the topic regularly, without the #post-1, the bug doesn't happen.
it also doesn't happen when accessing the forum through the regular URL:
https://solutio.talkyard.net/-79/payment-process-grant-version#post-1
Error 500 Internal Server Error
Something went wrong: [DwE500REX]
java.lang.RuntimeException: 1699054208|LcHtEYdAWq3y [TyE2ABK49Z3]
at com.debiki.core.Prelude$.die(Prelude.scala:297)
at com.debiki.core.Prelude$.dieIf(Prelude.scala:317)
at talkyard.server.security.XsrfOk.unixSeconds(package.scala:43)
at talkyard.server.security.EdSecurity.checkXsrfToken(package.scala:759)
at talkyard.server.security.EdSecurity.checkSidAndXsrfToken(package.scala:545)
at talkyard.server.http.PlainApiActions$$anon$1.invokeBlockAuthViaCookie(PlainApiActions.scala:444)
at talkyard.server.http.PlainApiActions$$anon$1.invokeBlockImpl(PlainApiActions.scala:262)
at talkyard.server.http.PlainApiActions$$anon$1.invokeBlock(PlainApiActions.scala:137)
at talkyard.server.http.PlainApiActions$$anon$1.invokeBlock(PlainApiActions.scala:110)
at play.api.mvc.ActionBuilder$$anon$9.apply(Action.scala:379)
at talkyard.server.http.PlainApiActions$$anon$1.$anonfun$composeAction$1(PlainApiActions.scala:124)
at talkyard.server.http.SafeActions$ExceptionAction$.invokeBlock(SafeActions.scala:126)
at talkyard.server.http.SafeActions$ExceptionAction$.invokeBlock(SafeActions.scala:83)
at play.api.mvc.ActionBuilder$$anon$9.apply(Action.scala:379)
at play.api.mvc.Action.$anonfun$apply$4(Action.scala:82)
at play.api.libs.streams.StrictAccumulator.$anonfun$mapFuture$4(Accumulator.scala:168)
at scala.util.Try$.apply(Try.scala:213)
at play.api.libs.streams.StrictAccumulator.$anonfun$mapFuture$3(Accumulator.scala:168)
at scala.Function1.$anonfun$andThen$1(Function1.scala:57)
at scala.Function1.$anonfun$andThen$1(Function1.scala:57)
at play.api.libs.streams.StrictAccumulator.run(Accumulator.scala:200)
at play.core.server.AkkaHttpServer.$anonfun$runAction$4(AkkaHttpServer.scala:429)
at akka.http.scaladsl.util.FastFuture$.strictTransform$1(FastFuture.scala:41)
at akka.http.scaladsl.util.FastFuture$.$anonfun$transformWith$3(FastFuture.scala:51)
at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
at akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(BatchingExecutor.scala:63)
at akka.dispatch.BatchingExecutor$BlockableBatch.$anonfun$run$1(BatchingExecutor.scala:100)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:85)
at akka.dispatch.BatchingExecutor$BlockableBatch.run(BatchingExecutor.scala:100)
at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:49)
at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(ForkJoinExecutorConfigurator.scala:48)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
KajMagnus @KajMagnus2023-11-08 10:54:44.368Z2023-11-08 13:01:38.705ZThat's odd, looks as if in the XSRF token, there's a pipe
|instead of a dot..The notification, is it a link in an email, or is it in one's username dropdown menu in the forum?
Can you still reproduce the bug? If so, what if you open Dev Tools, start a recording session in the Network tab, then reproduce the bug, and then right click anywhere in the network requests list, and select Save all as HAR with content and send to me in a PM or email? (Then I'd also get your session cookie, but, hmm, I have access to the server anyway. Nevertheless, you'd better log out & in again, some time later.) — Sorry for the distraction from what you would otherwise have been doing.
Or if that's too intrusive — what if you open Chrome Dev Tools (if you use Chrome): CTRL+I, then click the Application tab, click Cookies to the left (below Storage), and copy the value of the
XSRF-TOKENcookie, and send in a private message? Hmm seems it's already included in the error log message, but might be good to copy it via Dev Tools too.***
This weird XSRF token (with a
|) is old, from before HTTPS started working, but I'm still confused about how the|not a.has happened.(Old? The first part of the XSRF token, is a timestamp, and it's from Friday November 3, which is before I added HTTPS to the forum, which was on November 5.)
I suspect that if you log out, and log in again, the problem will be gone. Hmm at the same time, then maybe we cannot reproduce it any more. — Still, I could add a warning log message to the server, and auto-generate a new XSRF token if this happens again.
When accessing via the
.... talkyard.netdomain, the XSRF cookie won't get sent (different domain) so then the server never sees the unusual|instead of., so the error won't happen.About the url ending with
...#post-1, or without#post-1. Somehow, the#post-1request is (or triggers) a HTTPPOSTrequest, which triggers the XSRF check. But when you access without#post-1, then a normalGETrequest happens, and then the XSRF check won't run, so the error won't happen. — Does the error message pop up immediately? Or is there a small delay? (In the latter case, maybe it's in fact another request, which tracks reading activity, that in fact triggers the error. It's aPOST.)(You're using "normal" browser, not cURL or some other tool?)
@Mr.NobodyThe notification, is it a link in an email, or is it in one's username dropdown menu in the forum?
it is the in-app notification in the forum. But if I copy the URL and paste it into a new window it also happens.
However, today this bug isn't appearing anymore. It is however appearing when I try to resume the editing of a draft.
Can this be because I added the new domain but didn't enable to redirect yet? in the normal URL this issue doesn't happen, just in the new "custom" url. I haven't enabled the redirect yet though, because of this issue.So I am sending you the recording of the draft issue per email.
KajMagnus @KajMagnus2023-11-09 07:21:32.658ZThanks! I've had a look at the HAR. It looks as if the weird XSRF token is not Talkyard's cookie. You have added some custom Javascript code? Some plugin maybe?
XSRF-TOKENis a pretty common name for XSRF cookies (for example, AngularJS use(d) it as its default XSRF cookie name). And in the HAR file, I see another cookie that also isn't Talkyard's. I replied to the email a bit about that.So, I think I'll rename Talkyard's XSRF cookie to
TyCoXsrf, so there won't be any cookie collisions in the future. I'll do, and release a new server, together with a few other bug fixes.(In the HAR file, I see both this "weird"
XSRF-TOKENcookie with a format that makes Talkyard say "Error", and also Talkyard's ownXSRF-TOKENcookie, the precise same name and with the expected format & contents. But it appears later in the cookie header, so Talkyard won't use it — instead, the "werid" cookie value gets used instead.)(It was indeed a
POSTrequest tohttps://forum.solutioapp.com/-/mark-as-seenfor tracking reading activity that triggered the error, not the view-pageGETrequest — Talkyard was trying to mark the page as read.)Can this be because I added the new domain but didn't enable to redirect yet? in the normal URL this issue doesn't happen, just in the new "custom" url
The old domain (at Ty .net) probably doesn't have those extra cookies, for some reason.
- In reply toMr.Nobody⬆:KajMagnus @KajMagnus2024-01-29 12:55:59.544Z
@Mr.Nobody — Now this should have been fixed. The cookie now has a new name:
__Host-TyCoXsrfand it won't matter if there's anXSRF-TOKENcookie with some "unexpected" value created by other software. That unexpected XSRF cookie value might actually have been set by other software on the base domain (e.g.example.cominstead ofwww.example.com), which would then get sent to subdomains (e.g.forum.example.com). But now Talkyard uses__Host-only cookies, so that can't happen anymore.And everyone got logged out from everywhere (the session cookies were renamed too). (You're logged out here, and at your own forum.)
- Progresswith handling this problem