Wt

I just added "-c wt_config.xml" to the command line above, and now it works.

It's interesting that the log still has it in the GET and POST, but it's not showing up in the URL bar on the browser. Why??

sudo ./hangman.wt --docroot ".;/resources" --http-address 0.0.0.0 --http-port 8181 -c wt_config.xml
Password:
[2023-Feb-02 17:23:00.537] 6604 - [info] "config: reading Wt config file: wt_config.xml (location = './hangman.wt')"
[2023-Feb-02 17:23:00.538] 6604 - [info] "Auth.GoogleService: not configured: OAuth: no 'google-oauth2-redirect-endpoint' property configured"
[2023-Feb-02 17:23:00.538] 6604 - [info] "WServer/wthttp: initializing built-in wthttpd"
[2023-Feb-02 17:23:00.539] 6604 - [info] "wthttp: started server: http://0.0.0.0:8181"
[2023-Feb-02 17:23:14.779] 6604 - [info] "Wt: session created (#sessions = 1)"
[2023-Feb-02 17:23:14.779] 6604 [/ TDXhiduhbnVeaBKB] [info] "WEnvironment: UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
Dbo.backend.Sqlite3: begin transaction
Dbo.backend.Sqlite3: rollback transaction
[2023-Feb-02 17:23:14.789] 6604 [/ TDXhiduhbnVeaBKB] [info] "Using existing database"
127.0.0.1 - - [2023-Feb-02 17:23:14.802] "GET / HTTP/1.1" 200 4601
[2023-Feb-02 17:23:14.802] 6604 - [info] "WebRequest: took 22.855 ms"
127.0.0.1 - - [2023-Feb-02 17:23:14.850] "GET /?wtd=TDXhiduhbnVeaBKB&sid=819754098&webGL=true&scrW=3840&scrH=1600&tz=-300&tzS=America%2FNew_York&htmlHistory=true&deployPath=%2F&request=script&rand=2265547212 HTTP/1.1" 200 50168
[2023-Feb-02 17:23:14.850] 6604 - [info] "WebRequest: took 12.149 ms"
127.0.0.1 - - [2023-Feb-02 17:23:14.970] "POST /?wtd=TDXhiduhbnVeaBKB HTTP/1.1" 200 47
[2023-Feb-02 17:23:14.970] 6604 - [info] "WebRequest: took 0.931 ms"

There's two reasons why Wt would put the session id in the URL:

• It's a plain HTML session (JavaScript is not available)
• <reload-is-new-session> is set to false

Maybe when you don't specify -c wt_config.xml it's reading the config from some location where <reload-is-new-session> is set to false?

When an old session ID is supplied Wt normally just starts a new session, though, it shouldn't give you a Forbidden error. If possible, can you provide steps to reproduce it?

Putting the session id in the URL for GET and POST requests (sent by the JavaScript code) is how we identify the session, but we indeed normally don't put it in the URL bar unless it's absolutely necessary.

Oh! I had not added to the list of possible reasons.

My app lets people build statistical models and I wouldn't want them to be in the middle of modeling something, hit refresh/reload on the browser, and lose their work to a brand new session.

Mine is set to false for that reason. So, that means I will always see the /?&wtd= in the URL bar?

If URL-based session tracking is used (the default), then setting reload-is-new-session to false necessitates that the session id is put in the URL, so that Wt knows which session to resume when you refresh.

Perhaps we could do this differently using sessionStorage, but it likely won't be straightforward to change Wt to work that way.

Got it. In that light it makes perfect sense. ok, I guess I'll live with it. The Forbidden error is very rare and I think it's most likely Wt's way of preventing bad-actors from hacking the system.

Roel Standaert wrote in RE: Getting rid of /?&wtd= (yes, this topic, again....:

When an old session ID is supplied Wt normally just starts a new session, though, it shouldn't give you a Forbidden error. If possible, can you provide steps to reproduce it?

A couple of my testers are still getting the Forbidden error on occasion. It's not the norm, but it does happen.

I DO have <reload-is-new-session> set to false, and it needs to be that way. Not sure if that is causing it.

It seems to happen when the user navigates back to the page where the app is loaded and just hits enter without clearing the "/?&wtd=" ID from the URL. I've since added SSL certificates to the site, so everything happens over https. However, I do NOT have https or SSL between the server and the load-balancer. The user comes in via 443 and gets re-directed to 8181. Could that be it?

Are you sure it's Wt that's sending the 403? Can you check whether Wt logs the 403 response?