Can a client be created to only receive a read-only copy of the cache
such that the client application is not allowed to make changes to
the local cache nor make changes that will reflect on the server
nodes.
I have started a process that acts as a client for a gemfire server.
I would like to fetch all the cached data from the server at once in
the client side of the cache and only then continue with regular
functions of the client. Is there a way the client can make a call to
fetch all data it is interested in and get notified when all the data
has arrived in its local cache?
You can use GemFire security to create a read only client. You will need to implement com.gemstone.gemfire.security.AccessControl interface on the server side to reject all write requests from the client. You would also want to implement the Authenticator interface on the server to establish the client's identity.
From the client you need to pass in the credentials using the AuthInitialize callback. Please refer to the security section of the documentation and this wiki page for more details.
Regarding your second question, I would like to ask if your client is capable of caching all server side data, why do you need a client/server architecture? Could you not embed the server within your application itself?
Related
I have created an API that should only be accessed by certain client applications.
The users of these applications do not (necessarily) have to log in to use the client application. I will hand out API keys, but these will be visible on the client app, so they can also be used by other applications (?).
Is there any way to make sure the requests are coming from a specific client application, for example because they are hosted on a certain domain? I guess origin headers can easily be spoofed.
API keys are typically used to authenticate applications to a server. You are not saying what type of client you are using (native, web app, JavaScript?) You're correct that the API key may be read by another application on the client if that client has the same permissions (running in the same security context) as your client.
You could use client certificates to have the application identify itself. But this may be a pretty heavy-handed solution depending on the security thread you're trying to mitigate. And even here an application in the same security context has access to the private key.
All other info in an HTTP request is easy to falsify.
We are using worklight 6.1 and want to use encrypted cache on client side but before implementing it we just want to confirm whether this require any server call or not.
When we do any call to this api whether worklight server connection is required or not?
At the time of calling this api whether worklight server is storing anything related to it?
We don't want server call so please suggest whether this is correct choice for storing sensitive data on client side?
When using WL.EncryptedCache, a call is made to the Worklight Server in order to generate a random number, so at the very least Internet connectivity is required.
If you don't want this, you should opt to using the JSONStore feature instead, which is more powerful and feature-rich.
Note the following if you opt to use JSONStore:
When the localKeyGen key is present in the JavaScript implementation
of the JSONStore API, and it has a value of true, a cryptographically
secure token is generated locally. Otherwise, the token is generated
by contacting the server, thus requiring connectivity to the
Worklight® Server. This token is required only the first time that a
store is opened with a password.
Read more
An example of how you would pass the flag:
WL.JSONStore.init(..., {localKeyGen: true})
.then(...)
.fail(...);
I'm working on a Windows Phone 7 application, and to go with it I will need a web service to send out live tile push notifications. I will save the clients URI channel in a database and every hour or so I will send out the correct live tile to all the subscribed clients. I will not be sending out any sensitive data to the clients, nor do the clients send any data to the service save for their channel URI, and I've made sure to protect the database against any sql-injections.
The exposed methods are for registering and unregistering a client, as well as sending the correct live tile to a client that requests it.
Given this information, does anyone have any recommendations on how I should secure the service, or is security even needed to begin with in this case?
Thanks!
EDIT:
Thanks for the answers! My peers decided to not use any security at all though, other than purging faulty requests from the database, since the scope of the application is quite limited and no sensitive data is being transmitted. Let's hope it won't bite us in our behinds later on, eh!
Unfortunately the best solution to this problem (at the moment) is to generate a hash in your app and use that to verify the data is really coming from your app. Obviously you'll need to obfuscate tyour code if doing this.
This is the best you can do without any authentication against the backend.
If you can, have the users register and authenticate with the backend and then tie this authentication token to the ANID of the device and do everything over SSL.
Unfortunately, currenlty, security of services and prevention of spoffed requests is quite tricky with WP7 without requiring a login to the backend.
Make sure you secure your channel to your backend service with SSL. This way the data you send to the server such as a the ChannelUri will be secure.
Building a hash into your application isnt security. People could get your XAP and decompile it to get the hash.
IMHO you are better to ensure your ChannelUri (unique to your app and not "stored" in your XAP anywhere) is secured when you send it.
On the backend just make sure you purge records that fail when you try and send it a tile notification. This will get rid of any records entered by non-phone parties.
Bottom line is that you need a login infrastructure with your backend to properly ensure only valid users are using your service.
Here's the set-up:
I have a server-based application. So, all the data is on a server (call it server 'A') and users connect to that server using a desktop-based rich client. The rich client also allows the user to connect to some other server (call it 'X'), that is completely unrelated to server A.
Question:
The user has logged into server 'X' from the rich client, and so the rich client has the right cookie to authenticate against server X. Now, the user makes an invocation on server A, which requires server A to go out and get some data from server X. Is it possible to somehow circumvent having server A to authenticate against server X given that the rich client has already authenticated against server X. Is there some way to share the cookie (with server A acting as the second client)? Or some way to have server A forward server X's authentication request back to the rich client and having it resolve against the cookie in the rich client. BTW, we use apache's HttpClient.
I am not very knowledgeable about server interactions, but am trying to gauge how easy/hard or common/rare is it to do something like this. Is it even possible to do this in a secure manner?
On a basic level, all HTTP communications are text data being passed back and forth between a client and a server. So, if you extracted the cookies from the Server X response and passed them in the request to Server A, then as long as A understood to extract the cookie data and insert the cookies into a new request to Server X, you would be successful in achieving what you are asking.
In a nutshell.. cookies are simply text data that gets passed back and forth between servers and clients. You can grab that data and pass it wherever you like. (you'd probably be breaking a lot of security best practices, though)
However... many servers are getting smarter about request forgery attacks and the fact that the remote host, client ip, etc... are different may invalidate the request or at least alarm Server X. So test thoroughly on all test/stage/prod platforms before making any blanket assumptions about the viability of the strategy.
If you control the behavior of the "rich client" then yes, sure. Just look at what cookies you have for the server you're about to access, if it includes your user login tracking cookie you're set, if not, look at the cookies for the other server and copy any user login tracking cookie that you have there, if it exists, into the cookie pool for the request you're about to make for that server.
Presumably, because you're trying to share users, the two servers share a user database that has common userIDs or other hashes which you're using in these cookies.
If on the other-hand, the only user tracking you have in place now is essentially session based, where the cookie contains a hash for the session and that session is stored on the server side, then unless the two servers share the session store, you will not be able to simply hand off identical cookies from the client side.
hello i have a desktop application that communicate with a wcf service that i building as well
i want to be able to manage the logged on users inside the server without a db (statefull server)
i also want the server to know how to handle 2 client from same computer, whats the simplest way of doing it?
i also have more than 1 service that the client work with (login service and app service)
is there any operationContext Property that can help me?
You can deffinetly manage the logged users inside the server. I have created a personal pattern for dealing with such situations, and it ussually goes like this:
create a client class inside the WCF server that will hold all the needed information about the client.
create 2 methods in the service: logIn, logOut. the login method should be able to gather all the informations about the client that you want to store. Make sure to define properties that can uniquely identify a client instance. When the client conencts to the server it calls the login method, allowing the server to gather and save the information from the client. If using callbacks, this is the place to save the CallBack context object, in the client obejt. You can now save the Client object in the WCF server instance (I use a dictioary). When the client logs out, it calls the log out method and the server removes the entry.
create a KeepAlive method in the server that regularry checks the connected clients to see if they are still connected (in case of network failure or app crash a client may not call the logout method).
I think this is the simplest way (not saying it's the best) to manage clients in the server.
There is no problem with having multiple clients from the same computer (you save the Context when a client logges in) as long as you have a way of uniquely identify clients.
As for your last question, having multiple services should not be a problem. In fact you have the same WCF server with different contracts (and endpoints) for the different services you offer. ALl the contracts reside in the same WCF server instance so they all can access the connected client list.
If you have further questions, I would be happy to answer them.