Hacker News Reader

Correct me if I'm wrong, but to me passing the access token in the GET URL is not a good security practice. This increases the probability of unintentionally exposing the token. The URLs can be logged by proxy servers, application logs. Simply, user can accidentally send the link with token in chat, etc.

Usually in REST APIs the auth token is passed via some HTTP header.

A stackoverflow answer on this:

https://stackoverflow.com/a/499594

I don't think proxy servers or sniffers see GET data - it's encrypted, assuming HTTPS of course. Server logs might be an issue. Browser logs and accidentally sharing is definitely a bigger issue. Less of a concern if API is only used behind the scenes by apps though.

Disclaimer: I'm not an auth expert!

> I don't think proxy servers

Proxies with MITM (mostly corporate) would see everything, because they are terminating client SSL/TLS.

MITM will see everything, but this should be the case with headers as well as GET params, passwords/tokens/data etc.

In case there is no MITIM but the original link was written using the plain HTTP then the proxy would see it anyway, before upgrading to SSL CONNECT.

> Usually in REST APIs the auth token is passed via some HTTP header.

Yes, headers or even as a data in the POST request.

> Simply, user can accidentally send the link with token in chat, etc.

Yep! Even more - it can be seen in the URL even if the user send a screenshot.

Are headers/POST data safer in any way against an attacker? Do they get any special treatment while the data is in-transit, as of being usually more often encrypted than the visible request URL?

There is no defence against an attacker sitting on your wire. But headers and data 99.9% aren't logged or can be seen in a shared link or screenshot.

Just hit F12 in you browser, switch to the Network tab and look what happens when you do the things.

TL;DR: no, but you should be vary of how things are logged and/or shared.

Eg: you see a screenshot with https://bank.com/pay.php?from=17255252&to=6445675665&amount=... URL in the browser...

Yeah, true, even a security camera pointed at your laptop's screen would have access to GET data and not POST data.

Hi, i'm new to HN and didn't find comments easily! Sorry for late reply.

Having them in the query params was intended for sharing indeed. I wouldn't expect someone using it on the frontend of course. I might switch to having them in the headers instead, as it was initially like that. Idea was to use the service with minimal requirements.

Tokens can be set as READ_ONLY, these tokens are only meant to be used with GET requests. So you can share the link to use in some other app for example. Again, headers might be better however we can't share them, i.e. simple copy paste.

First let me say that the minimal interface you've designed for the dashboard is lovely. But also consider that as you talk to potential customers for this, the hardest sell is "send your data to a third party" and the easiest sell is "here is something that will save your developer's time". The biggest problem it seems like most people are facing now is getting their data transported between services.

> The biggest problem it seems like most people are facing now is getting their data transported between services.

Could you elaborate a bit?

Pretty much every tech company is built on a stack of SaaS products (Google suite, CRM tool like HubSpot, etc), and it seems like a lot more innovation is going into integrating/standardizing their APIs.

If you're just focusing on making a pure developer tool, a good example of successful execution is cronitor.io.

Thanks! And I fixed some bugs in the meantime. Yes, and the API should maintain its simplicity without making it super complex. And I'm still considering moving token to the headers instead of query params, as stated in one of the comments here. There are obvious pros and cons.

I'm a little confused after looking at your website. You're expecting someone to give you their personal data, there's no pricing information, there's no way to get their data back, and since they don't know anything about you, there's no restriction on what might be happening to their data. What I've written may or may not be true, but I'd expect anyone looking at the landing page to want those things to be addressed. You might have more luck if you offer a self-hosted version that folks can run themselves, and then once they trust you and decide they don't want the admin burden, they can pay you.

Disclaimer: I'm not your target audience, but I've investigated a lot of these services for my own things, and these are my feelings after an initial look at your website. I'd honestly not return for a second look under normal conditions.

Actually feedback from non-tech folks (assuming you as such) is very welcomed, so thank you!

The product is at early stage and I will be adding more texts of all sorts (like disclaimers) and features. Data is truly not shared with anyone, it's in a dedicated server, but it's NOT in an encrypted database for now. It will be when it's developed.

All that is collected from users is their email address, since you can sign up using Google and Github auth only. Behind this auth one can create apps, environments and access tokens. Afterwards, requests to the API are open under access token.

Product is free for now, thus no pricing info at the moment.

Seems like a good idea. It would have been revolutionary 10-15 years ago. But the db-space has gotten really crowed the last couple of years. And all have the focus on doing it simpler.

You should try to find your target audience and see how you can make nodb better then what ever db/solution that audience is using instead of nodb

Good luck!

Thank you. You're right it's overcrowded. I had passion to make it to use for my projects. I didn't want to install "npm install some-db", since I can't use persistence in cloud functions that way. Solutions exists like supabase, however I imagined separation of concerns as in apps/environments like in standard software projects beneficial for my use case.