I have a emailing system in a program. The person writes a email, sends it to a database, and several people will be allowed to retreive that email later on. However, these emails are sometimes short but are sometimes quite long.
Consequently I would like to compress these emails before sending them to the database (in the javascript on the client side), then uncompress them when they are retreived (again in the js on the client side).
Are there any libraries (free) that can do this? Is such a thing easy to write myself?
If you really want to do this at the client end, you can maybe look how JSend works - it's not designed to save space; it's designed to compress data for transportation, but it's an example of encoding/decoding data. You will probably need to write your own script that does a similar thing.
Remember, by making the client do the compression, you need it to work in every browser. A server side script is much more reliable (and efficient).
You may want to look at InnoDB Data Compression. If you can implement it, you might find that a native database process is much more efficient than anything you can do in Javascript.
Related
I have a SPA web page. Data are loaded with ajax requests. I need to show some culture sensitive data on that page. What is the best way for formating this kind of data?
Basicaly I have two options:
1. Send all data preformated to client (preformat on server)
Preformated
{
DurrationInMinutes = '2 min'
DurationInSeconds = '120 sec'
}
Pros:
Easy server side implementation (Asp.net mvc back-end).
Everything is in one place (one method in BLL).
Smaller JavaScript
Cons:
Posible data duplication (same duration data shown in minutes,
seconds i.e. diferent format but same data).
2. Send raw data to client (format on client)
RawData
{
Durration = 1645678 // milliseconds
}
Pros:
Easier unit testing (we can test everything in c#)
Easier maintenance - our developers are more expirienced in c# then
Javascript
Cons:
More work has to be done on the client side
I'm not sure if all data formating can be easilly done in javascript
Edit
I end up with client side option
Thanks
For just simple presentation of the data, both methods are OK. But keep in mind a couple of other considerations:
All data sent to the client is in principle available for the user, even if it's not shown directly. This can in some situations be a security issue.
Sending the raw data to the client and letting the client handle the rest gives more possibilities for dynamic viewing on the client side
Depending on type of application and data, sending data to the client can reduce load on server. However users with slow clients can be an issue.
If none of these considerations apply, I would go with what is most optimal for developing and maintenance. The answer then depends on local issues, resources, framework used etc.
I don't understand the cons of the server side option - how is is that formatting things once will cause that? Specially when you can keep your localized data in resource files, and simply let the framework handle the localization with a simple configuration? And yes, AFAIK, pure Javascript doesn't have all the same localization capabilities of .NET (or Java, or any other framework, for that matter).
Also, the pros of the client side option - How is it that coding in the side your dev are less experienced helps unit testing and maintenance? Do you think that just because it's not on server side, it doesn't have to be tested to be ok?
My two cents: unless you find a Javascript framework that can do that, let the server side handle it. Otherwise you'll be reinventing the wheel. Also take into account that the more logic you have on the client side, the worse your site look-and-feel will be on low end machines, tablets and cell phones.
I would like to encrypt and save a user password in a database, all this with javascript, and later decrypt it. I would like to use a key to encrypt/decrypt all passwords. I was thinking about storing them in an sqlite database.
Do you think this way the database will be secure in case of theft? I guess it will highly depend on the algorithm and implementation.
Can you point me in the right direction to any library that has this functionality, allows me to encrypt/decrypt?
Can you recommend me a library to handle sqlite db. with javscript?
I would normally do all this with some webscripting language without decrypting the pass, but I need to do this with js. and I am fairly new to the language. So any advices would be appreciated.
Thanks!
Client side code should not be used for securing a connection, as the Javascript code itself was loaded from the insecure connection and is thus prone to tampering.
Just load your script and do all sensitive communication through https and and you should be fine.
If you encrypting/decrypting anything, it should be done on the server.
A hacker can view the source code of the JS to figure out the hashing algorithm, and assuming they're using a packet sniffer or similar piece of software, compare that algorithm to the data sent by the user.
For what you want to achieve, you could connect to the server with HTTPS, and send passwords and receive authentication notices to/from the server via xmlhttprequest.
I do not know of any algorithms for doing everything on the client, probably for the reasons listed above. There are plenty of PHP hashing algorithms however. This site may be of use: http://phpsec.org/
Edit: (Read your comment on the OP) Doesn't Firefox offer this functionality already? In any case, saving passwords made on the local machine can be stored on the local machine. When a page is revisited, you could auto-fill the related password fields. The only security threat there is if the host computer is compromised. I don't know any code samples for this though.
In a previous question I asked about weaknesses in my own security layer concept... It relies on JavaScript cryptography functions and thanks to the answers now the striking point is clear that everything that is done in Javascript can be manipulated and can not be trusted...
The problem now is - I still need to use those, even if I rely on SSL for transmission...
So I want to ask - is there a way that the server can check that the site is using the "correct" javascript from the server?
Anything that comes to my mind (like hashing etc.) can be obviously faked... and the server doesn't seem to have any possibility to know whats going on at the clients side after it sent it some data, expept by HTTP headers (-> cookie exchange and stuff)
It is completely impossible for the server to verify this.
All interactions between the Javascript and the server come directly from the Javascript.
Therefore, malicious Javascript can do anything your benign Javascript can do.
By using SSL, you can make it difficult or impossible for malicious Javascript to enter your page in the first place (as long as you trust the browser and its addons), but once it gets a foothold in your page, you're hosed.
Basically, if the attacker has physical (or scriptual) access to the browser, you can no longer trust anything.
This problem doesn't really have anything to do with javascript. It's simply not possible for any server application (web or otherwise) to ensure that processing on a client machine was performed by known/trusted code. The use of javascript in web applications makes tampering relatively trivial, but you would have exactly the same problem if you were distributing compiled code.
Everything a server receives from a client is data, and there is no way to ensure that it is your expected client code that is sending that data. Any part of the data that you might use to identify your expected client can be created just as easily by a substitute client.
If you're concern is substitution of the client code via a man-in-the-middle attack, loading the javascript over https is pretty much your best bet. However, there is nothing that will protect you against direct substitution of the client code on the client machine itself.
Never assume that clients are using the client software you wrote. It's an impossible problem and any solutions you devise will only slow and not prevent attacks.
You may be able to authenticate users but you will never be able to reliably authenticate what software they are using. A corollary to this is to never trust data that clients provide. Some attacks, for example Cross-Site Request Forgery (CSRF), require us to not even trust that the authenticated user even meant to provide the data.
I am creating a Web Application using JSP, Struts, EJB and Servlets. The Application is a combined CRM and Accounting Package so the Database size is very huge. So, in order to make Execution faster, I want prevent round trips to the Database.
For that purpose, what I want to do is create some temporary XML files on the client Machine and use them whenever required. How can I do this, as Javascript do not permits me to do so. Is there any way of doing this? Or, is there any other solution which I can adopt in order to make my application Faster?
You do not have unfettered access to the client file system to create a temporary file on the client. The browser sandbox prevents this for very good reasons.
What you can do, perhaps, is make some creative use of caching in the browser. jQuery's data method is an example of this. TIBCO General Interface makes extensive use of a browser cache for XML data. Their code is open source and you could take a look to see how they've implemented their browser cache.
If the database is large and you are attempting to store large files, the browser is likely not going to be a great place for that data. If, however, the information you want to store is fairly small, using an in-browser cache may accomplish what you'd like.
You should be caching on the web server.
As you've no doubt realised by now, there is a very limited set of things you can do on the client machine from a web app (eg, write cookie).
You can make your application use the browser plugin Google Gears, that allows you a real clientside storage.
Apart from that, remember, there is a huge overhead for every single request, if needed you can easily stack a few 100 kB in one response, but far away users might only be able to execute a few requests per second. Try to keep the number of requests down, even if it means adding overhead in form of more data.
#justkt Actually, there is no good reason to not allow a web application to store data. Indeed HTML5 specifications include a database similar to the one offered by Google Gears, browser support is just a bit too sporadic for relying on that feature.
If you absolutely want to cache it on the client, you can create the file on your server and make your web app retrieve it. This way the browser will fetch it and keep it on the client cache.
But keep in mind that this could be a pain for the client if the file is large enough.
I transfer a fair amount of XML from the server to the client, in my application (250K-500K each time).
How can I compress it on the server, and decompress it on the client using standard JavaScript? Is it possible?
First, a scolding and possible workarounds. Second, a possible crazy solution.
The Scolding
If you're sending 250k - 500k back and forth between the client and server, you're doing it wrong. Look into
Only requesting and sending back the information you need
If there's information in the XML that doesn't change often, configure your web-server for aggressive http caching for these requests. Also, consider sending the "doesn't change often information" down with the initial page request instead of grabbing it from the server
Consider sending down JSON instead of XML. JSON is less verbose than XML and will usually take up less space. If your client-side code NEEDS an XML object, reconstruct it from the JSON you just downloaded.
If you're using apache, mod_deflate will gzip your data for client that can accept it. Last time I looked into gzip encoding on IIS it did it's zipping and unzipping on disk, which quickly became a bottle-neck in high load situations (YMMV)
The Crazy Solution
If you're hell-bent on trying the compress-in-javascript route, the LZ77 compression algorithum has been ported to most languages, including javascript.
Find the analogous code for your server platform, compress the XML, and then feed it to the code found in the link above. To avoid encoding issues, I'd try wrapping the compressed data itself in either XML or JSON when sending it down.
Javascript compression performance is going to be slow.as.molasses, which is why I discourage this route.
Is this HTTP type transfers?
The easiest way would be to look into compression at the web server side.
XML Usually compresses really well.