Am I missing something with history?

[fruitwerks]

I have a no-user configuration and this is deployed on my LAN only. I've looked at the issues and docs I can find and I don't have an answer. The closest thing I can find is a mention in issue 114. I have done a clean deploy with the newest build and I still have the same problem. If I leave the result page or even open another instance of ConvertX, my result is now NOT_FOUND. The files are still present on the server. I can click back and revisit the history, but the second the main instance is fired, the history is zapped. Any action that triggers the app to change the JobId gives this result.

My use case for this is to have no-auth and allow my wife and daughter to also use this. Upload something from laptop/phone/tablet, if they don't need it immediately, no problem, if they want to download it to another device, it should be in history until the max time or items start bumping stuff out.

[NickJ-7010]

I have just installed ConvertX today and experienced the same thing. I think it has something to do with how ConvertX handles sessions if you don't enable authentication and accounts. My current understanding is that every device gets its own session ID (or account ID) that is ephemeral based on the auth cookie. Without being linked to an account, each auth token is treated as a new account and so the history is segregated out because you wouldn't want someone looking at the history for someone else's account.

My use case is similar in that I have no accounts and no auth as it runs locally behind my tailnet and I want to be able to upload and convert files from my phone and download them on my desktop.

I think there are a couple of solutions that can be applied depending on how the project works technically (I haven't looked into the code yet and so i'm not confident that what I am saying is true or possible).

I think that if you disable account registration all uploaded and converted data should be saved under a single possibly hard-coded account that all unauthenticated people share. if that is not feasable then all history should be pooled together regardless of pseudo account it was uploaded / converted under. You could also have some other way of handling accounts and session tokens when you have authentication disabled, but I would love to hear back from the maintainers on this issue as I think it is a pretty big use case for their project.

[fruitwerks]

I had a feeling this was the case but I haven't had time to dive into the code. Hopefully your fix gets merged.

Cheers.

[C4illin]

Sorry for the slow response.

Great idea and PR! I think adding a new env variable for this is the best, would that work for you?

[fruitwerks]

@NickJ-7010 Awesome fix. @C4illin Confirmed this works - you can close this issue.

Thank you both!

[C4illin]

Will close it when the feature is released