I'm currently using the node-jsonwebtoken (https://github.com/auth0/node-jsonwebtoken) library to generate an auth token. I simply call jwt.sign to generate the token.
On my staging and development servers, the token that is generated is 941 characters, but on my production server (with 8x the number of CPUs and larger RAM but no other differences), it is much much larger (>8KB). Does anyone know why this is -- best guess for me right now is that it's generated based on my RAM or multiple CPUs, but that's just a correlation.
What should I do to lower the size of the token? On my client, I'm not allowed to send requests with headers that exceeds 8KB.
Thanks
Related
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.
I have a working HTTP RESTful API that will receive an ID, then check against data in the database. Based on the status of the record and related records it will then return either state errors or if everything is ready to begin it will return some information about the records. It has some other functionality as well but my issue is our device we are using to collect this data does not have access to WiFi, we are planning on testing a 2G cellular solution but I know an HTTP request will be far too slow if it even completes.
What lightweight protocol can my device send a 36 char UUID to a server and get a JSON response back. I have been exploring information about MQTT and COAP but don't see much info on asking another device about a specific ID of a record it's more like ask for a hardware's status.
Furthermore, if there is a solution I can get to interface with my existing API this would be ideal.
Thanks for any help.
I'm not sure why the 2G cellular solution wont play well with HTTP(S).
according to another SO answer the size of http is:
Request headers today vary
in size from ~200 bytes to over 2KB. As applications use more cookies
and user agents expand features, typical header sizes of 700-800 bytes
is common.
And according to wiki you can get up to 40kbit/s. I'm not really sure what the issue is with using http(s) for this scenario.
If you use something like UDP it can be quicker and is smaller however, it's not as reliable as HTTP due to packet loss possibilities. Not to mention you can also apply gzip or another form of compression on the HTTP request to make it even smaller.
minor update
If that data is not needed right away you can do it hourly or half day batch uploads, store all the data in a local db and at certain time intervals do 1 main HTTP request that is a bit bigger but will have all the data? I'm not fully sure what your requirements are but HTTP should be fine for your case over 2G
Okay guys, I have followed these answers
413 Request Entity Too Large
add client_max_body_size 20M in nginx.conf and also inside httpd.confd folder which is related with my proxy configuration. I added in http, server and location block. I use Play! Framework as my gateway.
But still, I'd have Request entity too large error. Do you guys have any idea or suggestions? Or link to follow through?
Thanks
As well as the web servers in front of Play, which it sounds like you have configured, Play itself has max request Content-Length limits, documented here: https://www.playframework.com/documentation/2.5.x/JavaBodyParsers#Content-length-limits
Most of the built in body parsers buffer the body in memory, and some
buffer it on disk. If the buffering was unbounded, this would open up
a potential vulnerability to malicious or careless use of the
application. For this reason, Play has two configured buffer limits,
one for in memory buffering, and one for disk buffering.
The memory buffer limit is configured using
play.http.parser.maxMemoryBuffer, and defaults to 100KB, while the
disk buffer limit is configured using play.http.parser.maxDiskBuffer,
and defaults to 10MB. These can both be configured in
application.conf, for example, to increase the memory buffer limit to
256KB:
Depending on the situation, you may want to be careful with increasing this limit too much -- if you have untrusted clients they may be able to overload your server by sending lots of very large requests in a short space of time. This may cause your server to crash with an OutOfMemoryError, leading to a denial of service attack.
I am currently working on Charts in ExtJS, it is taking much time to display the graphs in browser.
Because the number of requests sending to server are more only for graphs.
How to reduce these no.of requests and improve the performance of my graph in EXTJS.
Can you help me regarding this ?
Thanks in Advance...
Have you considered using Ext Direct for its method batching support?
The idea is that you should receive data in a few large requests, rather than many smaller ones. Each browser has a maximum number of outgoing requests (I think 6 is the default now), so if you are making more requests than this, then they will queue client side.
I'm building a client/server iPhone game, where I would like to keep third-party clients from accessing the server. This is for two reasons: first, my revenue model is to sell the client and give away the service, and second I want to avoid the proliferation of clients that facilitate cheating.
I'm writing the first version of the server in rails, but I'm considering moving to erlang at some point.
I'm considering two approaches:
Generate a "username" (say, a GUID) and hash it (SHA256 or MD5) with a secret shipped with the app, and use the result as the "password". When the client connects with the server, both are sent via HTTP Basic Auth over https. The server hashes the username with the same secret and makes sure that they match.
Ship a client certificate with the iPhone app. The server is configured to require the client certificate to be present.
The first approach has the advantage of being simple, low overhead, and it may be easier to obfuscate the secret in the app.
The second approach is well tested and proven, but might be higher overhead. However, my knowledge of client certificates is at the "read about it in the Delta Airlines in-flight magazine" level. How much bandwidth and processing overhead would this incur? The actual data transferred per request is on the order of a kilobyte.
No way is perfect--but a challenge/response is better than a key.
A certificate SHOULD use challenge/response. You send a random string, it encrypts it using the certificate's private key, then you get it back and decrypt it with the public key.
Depending on how well supported the stuff is on the iPhone, implementing the thing will be between trivial and challenging.
A nice middle-road I use is xor. It's slightly more secure than a password, trivial to implement and takes at least an hour or two of dedication to hack.
Your app ships with a number built in (key).
When an app connects to you, you generate a random number (with the same number of bits as the key) and send it to the phone
The app gets the number, xor's it with the key and sends the result back.
On the server you xor the returned result with the key which should result in your original random number.
This is only slightly hacker resistant, but you can employ other techniques to make it better like changing the key each time you update your software, hiding the random number with some other random number, etc. There are a lot of tricks to hiding this, but eventually hackers will find it. Changing the methodology with each update might help.
Anyway, xor is a hack but it works for cases where sending a password is just a little to hackable.
The difference between xor and public key is that xor is EASILY reversible by just monitoring a successful conversation, public key is (theoretically) not reversible without significant resources and time.
Who is your adversary here? Both methods fail to prevent cracked copies of the application from connecting to the server. I think that's the most common problem with iPhone game (or general) development for paid apps.
However, this may protect the server from other non-iPhone clients, as it deters programmers from reverse engineering the network packet interfaces between the iPhone and the server.
Have your game users authenticate with their account through OAuth, to authorize them to make game state changes on your server.
If you can't manage to authenticate users, you'd need to authenticate your game application instance somehow. Having authentication credentials embedded in the binary would be a bad idea as application piracy is prevalent and would render your method highly insecure. My SO question on how to limit Apple iPhone application piracy might be of use to you in other ways.