I believe that GWT achieves RIA through initial throwing of
objects and files to the client side initially. but what I do not
understand is that is it possible to control the amount of information
being thrown to the client side? cos this is because I do not want
sensitive information to be cache at the client side. these
information shall only be retrieved from server when requested.
these information should only be sent to the client only when
requested and should not be cached at the client side. does anyone
know if it is possible to control the amount of information being sent
to the client? can anyone enlighten me? would appreciate your help
sincerely.
See if you dont want to expose particular information on client side then keep it on server side and whenever you want that information then using RPC call you can get it on server side.And gwt cache things like images etc that on client side information only.It is not caching your information which is present in lets say database or server side.So you dont need to worry about it.And if you want more security then you can use encryption and decryption algorithms.And if you follow design patterns like mvc then that will be very good programming practice.I created one sample application so if you want you can take checkout from here
Related
I am working through some security concepts right now and I was curious if this method has been tried and/or if it is safe taking into consideration "Brute Forcing" is still possible.
Take for example a Microsoft WebAPI Template in Visual Studio where you access a endpoint using a "GET".
The Endpoint would be accessible by any user/application
The String value that a user/application would get from this endpoint would be the password they need, but encrypted using a "KeyValue"
After a TLS Transmission of this Encrypted Value, the user/application would decrypt the String using their "KeyValue"
Is this a secure practice?
Thanks for indulging me and look forward to your responses.
EDIT: Added Further Clarification with Image to Help Illustrate
Suppose the following 2 Scenarios:
Communication between Server and Client
a. Your Server serves the Client application with an encrypted password.
b. The Client can request any password.
c. The passwords are encrypted with a shared Key that is known by both server and client application
As James K Polk already pointed out:
A knowledgable Attacker can and will analyse your deployed application and at some point will find your hardcoded decryption key ("KeyValue"). What prevents him from requesting every password that is stored on the Server?
Rule of thumb here would be: "Do not trust the client side."
Communication between Server and Server
a. You have 2 server applications. Application A is acting as some kind of database server. Application B is your Back-End for a user application of some kind.
b. Application A serves paswords to any requester, not only Server B. With no type of authentication whatsoever.
c. Confidentiality is guaranteed through a shared and hard-coded Key.
I think you are trying to overcomplicate things hoping that no one is able to piece together the puzzle.
Someone with enough time and effort might be able to get information about your server compilation and/or be able to get the Code of Application B. Which again defaults in the scenario of 1. Another point is that there are enough bots out there randomly scanning ips to check responses. Application A might be found and even-though they do not have the shared key might be able to piece together the purpose of Application A and make this server a priority target.
Is this a safe practice?
No. It is never a good idea to give away possibly confidential information for free. Encrypted or not. You wouldn't let people freely download your database would you?
What you should do
All Authentication/Authorization (for example a user login, that's what I expect is your reason to exchange the passwords) should be done on the server side since you're in control of this environment.
Since you didn't tell us what you're actually trying to accomplish I'd recommend you read up on common attack vectors and find out about common ways to mitigate these.
A few suggestions from me:
Communication between 2 End-points -> SSL/TLS
Authorization / Authentication
Open Web Application Security Project and their Top 10 (2017)
I am doing in a project using client-server communication through rest API, Angular 2 calling restful web service, for specific.
On client side, it is written in Typescript, a sub set of javascript.
My problem is our object on the server side is nested, complex and difficult to model/ deserialize exactly on the client side when it receives a response (JSON object)
My question is:
Do we need to make a class on the client side for all json
response object and deserialize them before binding it to the HTML
view or processing data?
And how big/complex could the response JSON object become a problem?
(Performance, Best practices...)
I am still confusing on how to share workload between client and server. What decides "we should handle it on server side" or "we should let the client do this"? Many of the cases I could let the server side fetch a lot of data before returning to clients, or should I let the client make multiple requests and fetch it on its side?
My application is probably an intranet application for ~ 1000 users (about 5-10 concurrently).
I am new to web application using rest, so I am greatly thank you if you guys could instruct me on this.
Let me answer to subquestion #3. I develop microservice architecture for a small project and have faced the same problem. It's possible to implement logic either at server side or at client side.
At one hand server could return simple plain objects, at another - could return objects containing all necessary nested and processed data.
In the first case, client should make more queries to the server in order to collect all nested data. The client should be more complex and foresee all the situations when server data could be changed during series of requests (keeping the consistency of data). But it really simplifies the server implementation - it could be just series of CRUD repositories. It could be even auto generated server over underlying DB.
In the second case, server returns complex nested object. It allows to simplify client, since JSON deserialization is pretty straightforward with modern frameworks. It reduces number of queries to server. If a client could have all the necessary data in one query - that's great.
In both cases the business logic should be implemented somewhere. I vote for the simple client and hiding complexity at server side. Finally, for one server could be several clients. That's why complex server will be more beneficial than complex client.
I need some advice on how propagating server-side changes of entities to the client is best handled with GWT's RequestFactory.
Let us assume we have two EntityProxies, a PersonProxy and a PersonListProxy (which has a getter for a List). Assume that the client has fetched a PersonList and a Person from the server.
In case the client is editing one of these proxies and firing a request, the machinery of RequestFactory (if I have understood the principles correctly) will fire an EntityProxyChange event if it detects changes done by server code (so that the client can update its display of the entities, for example).
Now assume that the server is changing its entities outside of a request by this client (e.g. due to another client calling the server) so that this client would see another version if it fetched the Person or the PersonList again.
My question is what is the best way inside the RequestFactory framework to tell the client of the changes (and to reuse as much of the machinery as possible)? We can assume that I have a way to send simple messages from the server to the client (e.g. Google App Engine's channel API or server-sent events).
One idea could be that the server sends over this channel a message telling that a Person or a PersonList with a specific id has changed. The client code handling the receipt of these messages could then use RequestFactory to re-fetch (e.g. find) the entity. This change should then be propagated to other parts of the client by an EntityProxyChange event.
Is this the way to go? (And in case that the client already has the current version of the entity, e.g. because the server was dumb and notified the client of changes the client itself made, would the triggered re-fetch just transport a few bits of metadata and not the whole entity again?)
ADDED:
Thinking a bit more about it, I wonder how EntityProxyId's can be generated for the server-sent event channel. When an entity on the server changes, the server only has the server id. It can then send it to the client, of course, but the client only knows of EntityProxyId's. Of course, I could add a getId() (in addition to getStableId()) to each EntityProxy, but it looks as if this would add redundant data to every server response.
Well, I realize that my post isn't precise answer to your question, but it's just my experience.
In fact, there is just a question how to deliver data from server to client.
I faced with some task couple years ago, and found for yourself an approach that make my life easier. To explain it, I want to specify my reasons:
You have to have full data delivery by requesting it from client - it's straight, natural way to requesting data;
You don't want to create and support 2 different models of full data delivery: one by requesting from client and second by pushing from server;
But you need to inform client about some changes on server side;
So, now I'm building my architecture using following approach:
Build full classical client-server API for data delivery - so you can load and refresh your application in natural way even if your pushing functionality is blocked or broken.
Define key information that may be changed on server side and should be delivered to client via push mechanism.
Create small push message construct(s) that will deliver to client just a notification about changes - no any valuable data should be delivered this way - just keys which data was changed.
All that is needed to do on client when it receives such notification is just to get/refresh data from server in natural client-server way that is already supported.
Server logic shouldn't bother client side by huge amount of notifications - sometimes is more effective do not deliver changes, but just refresh everything.
Hope this helps.
I am trying to make the sync data application in which user have some value into the data base .And he have to send this data on to the server .With help http request how can i do that .
I need the
I am not using the php web server .
I am using the Normal HTTP web page .
ANd i have the some data in my iphone application and i want to Synchronization that data to server .
I it must check the Internet is available or not .If the Internet is ON than only he will Synchronization the data .that's my question .
Nothing else .You got my point or not .
I thing people will reply me soon please
Thanks
You have got to have some kind of server backend for synchronization of the local database. You can't do that using just the static HTML pages.
Your application and server have to have a way to talk to each other using a web service protocol, like SOAP or JSON/REST. Then your application has to translate the data from the database into such web service data objects.
Both your local database and the server (in case of more than one client) will have keep the records of at least the times of last synchronizations so both know what should be sent over the air in order to become in sync.
Also, in the usual case of more than one client, you have to solve the problem of conflicts resolution.
Web service versioning is important as well, as there will be very likely a need to improve the communication channel, maybe there will be changes in the database model to be synchronized.
As you can see, the idea of synchronizing local database to a server is not that simple, and if you think you can do it in a simple way, in time you'll realise that you're gradually reimplementing the aforementioned ideas.
Do a research on web service technologies, writing web services-aware apps, on synchronization with web services and on Reachability, for starters.
To check internet availability, check out the Reachability class from Apple. See this article.
To send data to a simple HTTP form via POST use NSURLConnection like in this article.
Cheers,
S
I need to implement a process where users punch in a few details into a web page, and have this information fired as some
sort of an event to a Java rich client application (SWING) on the same host.
One idea was perhaps implementing an applet that would initiate socket communication with a listener implemented by the SWING
application, but not sure whether this is possible at all.
This sort of puzzling piece of integration is basically a given fact.
Essentially both the web application and the SWING one are already active and in use.
The only missing bit is sharing info between the two, in a way that would be easy to implement. no matter how dirty.
Any ideas?
Thanks!
Sounds a little confusing to the user if nothing else.
I would go one of two ways.
Have your rich client communicate over the network. And put whatever form you were going to have in the browser there.
Put your rich client into an applet.
Have both connect to a server somewhere (even locally), which your rich client can poll to see if the form has been filled in.