I'm creating a web application (in C++, for performance) where I'm expecting to process a tremendous amount of events per second; like thousands.
I've been reading about invalidating JWT tokens in my web sessions, and the most reasonable solution for that is to have a storage place for blacklisted tokens. The list has to be checked for every request, and what I'm wondering is performance related: Should I create a separate system for storing my blacklisted tokens (like redis)? Or should I just use the same PostgreSQL database I'm using for everything else? What are the advantages of using another system?
The reason I'm asking is that I saw many discussions about invalidating JWT tokens online, and many suggest to use redis (and don't explain whether it's just a solution relevant to their design or whether it's a replacement to their SQL database server for some reason). Well, why not use the same database you're using for your web application? Is there a reason that makes redis better for this?
Redis is a lot faster since its stored on memory of the server rather than opening a connection to the DB, querying and returning the results. So if speed is of importance then Redis is what you would want.
The only negative is if the server restarts the blacklisted tokens are gone. Unless you save them on disk somewhere.
Related
We have a setup wherein a Database instance is shared between multiple users.
We are trying to implement some form or throttling or Rate limiting for a shared PostgreSQL so that one user may not starve other users from consuming all the resources.
One approach that we can think of is adding connections pools and fixing the number of connections that we give each tenant.
But one user can still starve all the resource over a few connections. Is there a way to throttle resource usage per connection or per user in PostgreSQL?
No, the postgres documentation makes it clear that's not possible using Postgres alone.
It's usually a (very) bad sign if your application allows one user to starve resources from others - it suggests you've got a bottleneck in your application, and that bottleneck will appear when you least want it to.
From my point of view, session violates RESTfulness either when it is stored in the memory or db.
In case of session stored in the memory, it is hard to scale up the server using like load-balancing since servers don't share the session data.
Likewise in case of session stored in database, the database will be over-loaded when many servers simultaneously make queries.
My issue is related with the second case.
For a long time, I had thought that the server and database are different.
My past-assumption)
When client make request to the server with specific data, then server stores that data in the database like mysql or mongo etc.
So server don't have to care about the client's state since database has all control over them.
Server can stand alone against the client's request since server can make query to the database whenever wants to know who the client is.
So my two questions are that,
Whenever mentioning that "RESTful server stand alone against the client's request", is that 'server' includes database?
If yes, and if there is a User model and a Post-model associated with one-to-many relation, isn't that also violates RESTfulness?
I am sure that the second question makes no sense, since if the second question's answer is true, then RESTapi would have never been that useful.
But I cannot understand the difference between session in the database violates RESTfulness and the User-Post does not violate Restfulness.
I think that both of them are following the same procedure, client-server-database.
How can I understand this issue easily?
What's generally meant with statelessness is, summed up that : all the information to execute the HTTP request is self-contained within the request.
Some implications are that:
I can disconnect the TCP socket and re-open it, or I can keep a TCP connection open and it makes no difference. All the information to execute the request is contained within the request.
In the case of idempotent methods, I can re-do the exact same request and end up with the same state as if I only did it once.
In other words,
There are more complete descriptions of statelessness and HTTP, but the important thing is that statelessness here does NOT mean that the server cannot have any state at all. Most REST services are probably useless if there is no state.
Now to the question of whether having a session violates REST principals. I think it's hard to objectively state this either way. The important parts in relation to your question is that to be RESTful you need a concept of resources, a concept of being able to address them and a concept of transferring state between client and server. (there are more things that make up a REST service, but here are a few relevant bits).
I don't think having a means of authentication prevents this, whether authentication is done via an Authorization header or a Cookie header is not really that relevant.
If the session cookies and associated session data starts interfering with this process in other ways, it might be possible for a session-related feature to violate REST principals, but I don't think this is generally true.
If there are 'many articles' saying that sessions violate REST, I don't think there is any real basis for this. There is a lot of garbage descriptions of REST going around. I do think it might be bad for other reasons to use cookies for authentication. It does create potential for security issues.
Restful server is separate from the database.
Restful server, if there is such a thing, is just a web server.
REST is just an architecture, say a methodology, that delivers information from server to client and vice versa over HTTP.
I have an app that connects to different databases on a mongodb instance. The different databases are for different clients. I want to know if my clients data will be compromised if I used a single user to login to the different databases. Also, is it a must for this user to be root? to readWrite role will do the trick. I'll be co connecting to the databases through a java backend.
There is no straightforward answer to this. It's about risk and cost-benefit.
If you use the same database user to connect to any database, then client data separation depends much more on business logic in your application. If any part of your code can just decide to connect to any client database, then a request from one client may (and according to my experience, eventually will) end up in a different client's database. Some factors make this more likely to happen, like for example if many people develop your app for a longer time, somebody will make a mistake.
A more secure option would be to have a central piece or component that is very rarely changed with changes strictly monitored, which for each client session (or even request) would take the credentials accroding to the client and use that to connect to the database. This way, any future mistake by a developer would be limited in scope, they would not be able to use the wrong database for example. And then we haven't mentioned non-deliberate application flaws, which would allow an attacker to do the same, and which are much more likely. If you have strong enforcement and separation in place, an malicious user from one client may not be able to access other clients data even in case of some application vulnerabilities, because the connection would be limited to the right database. (Note that even in this case, your application needs to have access to all client database credentials, so a full breach of your application or server would still mean all client data lost to the attacker. But not every successful attack ends in total compromise.)
Whether you do this or not should depend on risks. One question for you to answer is how much it would cost you if a cross-client data breach happened. If it's not a big deal, probably separation in business logic is ok. If it means going out of business, it is definitely not enough.
As for the user used for the connection should be root - no, definitely not. Following the principle of least privilege, you should use a user that only has rights to the things it needs to, ie. connecting to that database and nothing else.
I'm currently planning a REST-style API. The problem I have is that the client will send one or more files, belonging to the same "document", but while the metadata is to be stored in a DB, the files are going to file storage (probably S3, in my case).
The way I see it, there are two ways of doing it:
Send the metadata to the API end-point, which responds with the location for storing the files. And then, in a separate request, store the files directly.
Send metadata and files, in the same request, to the API, which acts as a proxy and takes care of sending the various parts to their final destinations.
The good thing about 1. is that the API server will have less to deal with, so can be smaller, and bandwidth is only paid once (client -> storage). Giving a good UX is, on the other hand, likely to be harder, and there will be more state to keep track of.
With 2. it's easy to ensure the transaction is atomic, since the API server is the sole gatekeeper. However, the server will need to be more powerful, and bandwidth may be paid twice (client -> API -> storage).
So, what's the best way of dealing with this situation, and if going with 1. any problems to look out for?
Assuming you have external clients, I believe that #2 is the better bet. The way to catch and keep clients is to have the best possible UX, with a simple, easy to learn and use interface. As you said, you also get to keep atomic transactions, which will save you plenty of headaches. In my experience, server power is relatively cheap, and you can always send a 202 back to the client instead of a 201.
I have a bunch of web servers(frontends) behind balancer. Each apache process runs with it's own user for every virtualhost. Code that apache runs is PHP and it's not trusted code.
I need to have shared (between web servers) session storage and limit user(vhost) to only access it's session storage. So I want to avoid one tenant to be able to purge or corrupt memcached stored data.
So I basically looking for solution to authenticate users + create private buckets.
I know there is always MySQL way avaliable but I want to avoid performance penalty introduced by SQL layer.
Any solution in your mind so far?
I found product called CouchBase which fully comply with my requirements. It has buckets along with memcache caching layer and access protocol. It has SASL authentication and a bonus of load balancing and fail tolerance.