/api/login route is unreachable via curl

[SolninjaA]

Describe the bug
All /api/ routers are accessible except for /api/login when using a post request in curl. At first I thought Cloudflare was blocking the request, however I disabled Cloudflare and the issue still persisted. Furthermore, regardless of whether or not Cloudflare is enabled, the /api/ routes work fine when accessed through a logged-in browser (such as Firefox).

When Cloudflare is enabled, a 400 error is returned.

When curl -X post -d "PASSWORD" -c cookie.txt https://example.com/api/login is executed (and Cloudflare is disabled):

• If the user isn't logged in on their browser: "Request did not meet this resource's requirements."
• If the user is logged in on their browser: The command times out.

When curl -X post -H "Content-Type: application/json" -d "PASSWORD" -c cookie.txt https://example.com/api/login is executed (and Cloudflare is disabled):

• If the user isn't logged in on their browser: "Request did not meet this resource's requirements."
• If the user is logged in on their browser: The command times out.

If just curl https://example.com/api/login is executed, a 404 page is returned.

To Reproduce
Steps to reproduce the behavior:

1. Setup Chhoto URL instance
2. Run curl -X post -d "PASSWORD" -c cookie.txt https://example.com/api/login or curl -X post -H "Content-Type: application/json" -d "PASSWORD" -c cookie.txt https://example.com/api/login

Expected behavior
I expected for the /api/login route to be reachable and to return a valid cookie.txt file for further requests.

Screenshots
All screenshots would reveal my Chhoto password

Which version of Chhoto-URL are you experiencing the problem on?
v5.4.6 (gathered from the /api/version route when using a logged-in browser, showcasing that the routes are accessible when using a browser).

Can you reproduce the issue in the latest version?
Yes - to the best of my knowledge v5.4.6 is the latest version

Desktop (please complete the following information):

• OS: Arch Linux x64_84
• Browser: Hardened Firefox (Arkenfox)
• Browser Version: 133.0.3

Smartphone (please complete the following information):
Not applicable - I have not yet accessed Chhoto URL from my smartphone.

Additional context
Regardless of this issue, thanks for developing an amazing URL shortener. I intend to use it often.

[SolninjaA]

Update

It seems that the fix is to change -X post to -X POST in the curl command. I originally made this mistake because this is a typo in the README.md file: https://github.com/SinTan1729/chhoto-url/blob/main/README.md?plain=1#L154

[SinTan1729]

Hey @SolninjaA, thanks for taking your time and figuring out the issue. I'll correct the README presently.

[SolninjaA]

Hi @SinTan1729 . Thanks for responding so promptly! I just had a quick look, and it looks like the typo hasn’t been updated yet. Would you like me to submit a pull request? Of course, it’s not a major issue so it’s not urgent.

On a slightly unrelated note, I’m currently working on changing the API functionality of Chhoto URL and planning to merge my changes back to the main repository. Mainly because I’m also trying to make a web extension for Chhoto URL and I need the reworked API. If I were to edit the API in such a way that it is still lightweight, would you be interested in merging the code? I haven’t finished yet, but I just wanted to know if this is something you would be willing to merge in the future.

[SinTan1729]

Hi, I'll do it soon. What kind of changes do you want to make? If it's still lightweight, and doesn't change the API too much, I'll consider it.

[SolninjaA]

Sure, I can explain what I’m thinking of.

I originally started making an extension for Firefox that lets you create shortened links, etc without having to access the Chhoto URL instance webpage. However, right now when a user logs in the only thing returned is basically the equivalent of “Success!”. This is a problem for the extension because there is no equivalent of -c cookie.txt in JavaScript’s fetch() function (unfortunately I have to use JS for the extension).

One option is to avoid saving the cookie file to permanent storage, however if the user clears their cookies (which I do daily because of Hardened Firefox) then the program has to fetch another cookie. This effectively means the program would have to make a web request every time it is initialised.

It is much more efficient, and also leads to better error handling, to instead return a JSON response when the user logs in (or could instead be returned via accessing a route such as /api/create_key). This response would tell the application using the API whether or not the login was successful, and if not, return a proper error. However, more importantly it would return an ApiKey as well. Therefore the key can be saved, and only needs to be obtained once.

Basically, I’d just be modifying the api routes to also authenticate if an API key is supplied - rather than requiring a program to first visit /api/login and store the cookie file. Backwards compatibility would be preserved if this is a second form of authentication.

Either way, the most efficient way to do this is to make another table in the database for ApiKeys. That’s basically the extent of the performance overhead from what I can imagine. So far the database-route is the simplest and most efficient way in my testing. Otherwise the code becomes more complicated. I think the performance impact should be negligible.

Please let me know what you think. I’ve already made some successful changes, albeit I’m still working on it. Thanks :)

[SolninjaA]

That sounds like it would work! I'll try that idea, and see how it goes.

[SolninjaA]

Just giving an update - I decided to go down the route of having the user set an API key as a Docker environment variable. I tested password hashing, most notably with Argon2, however due to various limitations I decided this was not feasible.

I've now got a working prototype, and have retained full backwards compatibility. The resource usage is also very low (see attached screenshot)

I'm just going to be editing the code further, trying to test for bugs, optimize code where possible, etc. However, I had two questions I wanted to ask:

• When I built the Dockerfile, it gave an error on the line RUN cargo build --release --target=$target --locked --bin chhoto-url. I fixed it by changing --locked to --offline. This is different from the Dockerfile published in this repository though. When I submit my pull request, would you like me to keep --locked or change it to --offline (the latter is the only option that works on my system)?
• Would you like me to implement dark mode, as described here: Dark Mode #29

[SinTan1729]

Hi, thanks for your efforts. You can start by merging whatever's working, and we can work together to make necessary changes so that it matches the repo's coding style etc.

If you'd like to implement dark mode, feel free.

Also, I plan to add support for hashed password (and now also API key) so that they are never stored in plain text. It's something that you might wanna keep in mind. I'm on vacation right now, but if I get the time I might do it soon.

[SolninjaA]

Hi, I've just submitted the PR (#39). I didn't implement dark mode, as I figured I could always make another PR.

By the way, I have tested this with the Chhoto URL extension I am developing. I managed to remove a lot of code because of the overhauled API system. Thanks for being open to this contribution.

[SinTan1729]

When you have your web extension published, drop me a link. I can add it to the README.