How to use security in SD synchronization without GAM?
I need to block unwanted connections. How can I validate the execution of
Synchronization.Send () and Synchronization.Receive ()
I can not use GAM because I have to adapt my application to a pre existing security system.
There is currently no way for sending additional parameters or HTTP headers in the requests, so you'll need other means to identify your user.
One thing you could do, is call a procedure before synchronizing, passing the relevant information to identify the user (an authorization token or something like that). Then, you should validate that the next call is to the synchronization process, and check for instance that the IP address and the "device id" are the same.
Where would you validate the user's information, depends on which synchronization are we talking about.
For the Receive operation, you may perform your validations in the Offline Database object's Start event.
For the Send operation, everything is saved to the database by using Business Components. So you may add your validations in all the BCs that are involved.
Note: having said all the above, it is highly recommended that you use GeneXus Access Manager (a.k.a. GAM), where all this is already solved.
Second note: you should use HTTPS in all your connections; otherwise, none of this will be secure.
Related
I am trying to implement different cache strategies using ServiceWorker. For the following strategies the way to implement is completely clear:
Cache first
Cache only
Network first
Network only
For example, while trying to implement the cache-first strategy, in the fetch hook of the service-worker I will first ask the CacheStorage (or any other) for the requested URL and then if exists respondWith it and if not respondWith the result of network request.
But for the stale-while-revalidate strategy according to this definition of the workbox, I have the following questions:
First about the mechanism itself. Does stale-while-revalidate mean that use cache until the network responses and then use the network data or just use the network response to renew your cache data for the next time?
Now if the network is cached for the next time, then what scenarios contain a real use-case of that?
And if the network response should be replaced immediately in the app, so how could it be done in a service worker? Because the hook will be resolved with the cached data and then network data could not be resolved (with respondWith).
Yes, it means exactly that. The idea is simple: respond immediately from the cache, then refresh the cache in the background for the next time.
All scenarios where it is not important to always get the very latest version of the page/app =) I'm using stale-while-revalidate strategy on two different web applications, one for public transportation services and one for displaying restaurant menu information. Many sites/apps are just fine with this but of course not all.
One very important thing to note here on the #2:
You could eg. use stale-while-revalidate only for static assets. This way your html, js, css, images etc. would be cached and quickly served to the user, but the data fetched dynamically from an API could still be fresh. For some apps this works, for some others not so well. Depends completely on the app. Of course you have to remember not to change the semantics of your API if the user is running a previous version of the app etc.
Not possible in any automatic way. What you could do, however, is implement a msg channel between the Service Worker and the "regular JS code on the page" using window.postMessage API. You could listen for certain messages on the page and then, from the Service Worker, send a msg when an important change has happened and the cache has been updated. Then you could either show the user a prompt telling that the page really needs to be reloaded right now or even force reload it from JS. You would need to put this logic of determining when an important update has happened into the Service Worker of course.
(Let's ignore the fact that NSConnection is now deprecated.)
I have a tool that accepts connections to NSConnection over a service port. I have an application that launches the tool and then connects to it. That part works.
Now, I like to make sure that only my particular app can talk to the tool and that the tool rejects connections from any other tool/app.
How do I best accomplish this?
One idea I had:
Since the app starts the tool, it could pass a "secret" to the tool as an argument, and then I pass the same secret to the tool whenever I invoke one of its functions as an NSDistributedObject. However, that would mean I have to pass that extra argument to every call I make, and I think that's unnecessary overhead.
I would think that I could accept or reject the connection right when the app opens the connection to the tool, i.e. only once. There is the NSConnectionDelegate, and I suspect that I'd have to implement the authentication check in its authenticateComponents:withData: handler, but I cannot find any examples that would explain how to do that. I mean, is there any data in that connection attempt that would identify the app that's requesting the connection, such as its PID, for instance?
Do you establish a connection for every call? I wouldn't think so but, if not, why do you think you'd have to pass the secret for every call? It's pretty common for the server to have a check-in method that clients have to call. You could validate the secret in that check-in method.
A malicious client might try to just skip the check-in method. You can use the -connection:handleRequest: method of NSConnectionDelegate to force them to call the check-in method. Keep a flag for every connection indicating if you've seen the check-in method. If you have, that method can just return NO. If you haven't, then examine the NSDistantObjectRequest's invocation's selector. If it's the check-in method, set your flag and return NO. If it's not, then terminate the connection.
I know the underlying ports (Mach or socket) have mechanisms for authenticating peers, but I don't see a way to get at that with the abstractions of NSConnection laid over them.
Finally, you are apparently wedded to NSConnection but this is exactly the sort of thing that the NSXPCConnection API is for. Among other things, it will ensure that the service is only visible to the parent app.
I've been building some apps that connect to a SQL backend. I use ajax calls to hit WebMethods, a WebAPI, etc.
I notice that the first initial call to the SQL backend retrieves the data fairly slow. I can only assume that this is because it must first negotiate credentials first before retrieving the data. It probably caches this somewhere, and thus, any calls made afterwards come back very fast.
I'm wondering if there's an ideal, or optimal way, to initialize this connection.
My thought was to make a simple GET call right when the page loads (grabbing something very small, like a single entry). I probably wouldn't be using the returned data in any useful way, other than to ensure that any calls afterwards come back faster.
Is this an okay way to approach fixing the initial delay? I'd love to hear how others handle this.
Cheers!
There are a number of reasons that your first call could be slower than subsequent ones
Depending on your server platform, code may be compiled when first executed
You may not have an active DB connection in your connection pool
The database may not have cached indices or data on the first call
Some VM platforms may take a while to allocate sufficient resources to your server if it has been idle for a while.
One way I deal with those types of issues on the server side is to add startup code to my web service that fetches data likely to be used by many callers when the service first initializes (e.g. lookup tables, user credential tables, etc).
If you only control the client, consider that you may well wish to monitor server health (I use the open source monitoring platform Zabbix. There are also many commercial web-based monitoring solutions). Exercising the server outside of end-user code is probably better than making an extra GET call from a page that an end user has loaded.
I am developing a social network in ASP.NET MVC 3. Every user has must have the ability to see connected people.
What is the best way to do this?
I added a flag in the table Contact in my database, and I set it to true when the user logs in and set it to false when he logs out.
But the problem with this solution is when the user closes the browser without logging out, he will still remain connected.
The only way to truly know that a user is currently connected is to maintain some sort of connection between the user and the server. Two options immediately come to mind:
Use javascript to periodically call your server using ajax. You would have a special endpoint on your server that would be used to update a "last connected time" status, and you would have a second endpoint for users to poll to see who is online.
Use a websocket to maintain a persistent connection with your server
Option 1 should be fairly easy to implement. The main thing to keep in mind that this will increase the amount of requests coming into your server, and you will have to plan accordingly in order handle the traffic this could generate. You will have some control over the amount of load on your server by configuring how often javascript timer calls back to your server.
Option 2 could be a little more involved if you did this without library support. Of course there are libraries out there such as SignalR that make this really easy to do. This also has an impact on the performance of your site since each user will be maintaining a persistent connection. The advantage with this approach is that it reduces the need for polling like option 1 does. If you use this approach it would also be very easy to push a message to user A that user B has gone offline.
I guess I should also mention a really easy 3rd option as well. If you feel like your site is pretty interactive, you could just track the last time they made a request to your site. This of course may not give you enough accuracy to determine whether a user is "connected".
Imagine I have an existing process running under windows as a particular user. Would it be permitted for that process to take its current token (with something like OpenThreadToken and DuplicateTokenEx), pass it to another process on the same machine (perhaps through a network socket or some other IPC), and then expect that process to be able to use it to call CreateProcessAsUser?
From the documentation I have read (http://msdn.microsoft.com/en-us/library/ms682429%28VS.85%29.aspx), I've seen nothing which prohibits this but perhaps the token can only be used by the thread or process which created it.
(Why would you? I want to has a web request come to IIS, be authenticated, have IIS arrange the impersonation of the remote user and then pass the impersonation token to another server process (on the same machine) so that the server process can perform some security checks in the context of the remote user)
Yes, that is possible. You can use DuplicateHandle to get a handle that is valid for the target process (send the new handle value to the target process, so it knows it.).
However, the target process must still have the privileges to use the token accordingly. E.g. SE_IMPERSONATE to impersonate the user and SE_ASSIGN_PRIMARY to be used by CPAU. Of course there are some exceptions that you can read in MSDN for ImpersonateLoggedOnUser and CPAU.
I haven't tried it, but it seems that this is the same question asked here. The description seems to make sense. Pass the process ID via whatever mechanism you choose (e.g., IPC), then call OpenProcess, OpenProcessToken, and finally ImpersonateLoggedOnUser. The resulting handle could be passed to CreateProcessAsUser. Well ... I know it could be passed to that function but whether it would have the desired result I do not know. Interesting question, though.
Why not just use named pipes, and then call ImpersonateNamedPipeUser() - it's safe and secure and easy! Note that the process doing the impersonation MUST have the Impersonation privilege.