I am using Google's Error Reporting client in Golang - https://pkg.go.dev/cloud.google.com/go/errorreporting.
I'm wondering how I should use this for local testing, since calling Client.Report(e Entry) will panic if there are no credentials.
Options considered:
Pass in the environment (staging, production, etc) and only call the methods on the client if we are in an environment with credentials.
Check the client is not nil every time we use it.
Wrap the client and add nil checks.
Something else? I'm hoping to find a neater solution, e.g. a no-op client for use in testing environments.
Related
I have a very simple Spring application with cloud config client and oauth resources. It's turning out to be quite a challenge to run the unit tests without requiring the config server to be up.
None of the solutions out there for disabling cloud config client work for the latest version of spring. I have even tried to use empty or bogus config.import urls, but neither disable it. I really dont want to spin up the config server just for running unit tests and it doesnt feel like the correct way either.
What is the recommended way to setup tests for a config client application?
Looking for pointers, ideas.
Thankyou!
Making the configuration optional in test seems to do the job, though you still see an attempt being made to download the config.
spring.config.import: "optional:configserver:http://localhost:8888"
OR you can use
spring.cloud.config.enabled: false
However, client will always attempt to download the configuration, even though it appears to treat it as optional and moves on. I think this is really confusing for new users - one thinks the client is still enabled. What happens when the configserver is up and you expect the client to not download the config, but it still does. I guess the only way to find out is to test.
The weird part is that the following combination fails to load the context.
spring.config.import: "optional:configserver:http://localhost:8888"
spring.cloud.config.enabled: false
Either the import is set to optional or the config is disabled, but not both at the same time.
And, this is only for the tests. Creating another profile application-standalone.yml with same settings as test, fails.
(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.
My project: go - 1.12.5; gin-gonic; vue-cli - 3.8.2.
On windows server 2008 go under the local account, run main.exe - works well. But when log off my account, all local account programs are closed, including my go server.
The first thing I did was try to configure IIS for my GO. Nothing good came of it.
Then I tried to run main.exe from the SYSTEM account psexec -s c:\rafd\main.exe. When log off the process does not close. But the frontend is in my account and SYSTEM does not see the local files (js, html, css) of my project
Tell me how to start the Go server, to after log off my project did not stop life
Two ways to approach it.
Go with ISS (or another web server).
Should you pick this option, you have further choices:
Leave your project's code as is, but
Make sure it's able to be told which socket to listen for connections on—so that you can tell it to listen, say, on localhost:8080.
For instance, teach your program to accept a command-line parameter for that—such as -listen or whatever.
Configure IIS in a way so that it reverse-proxies incoming HTTP requests on a certain virtual host and/or path prefix to a running instance of your server. You'll have to make the IIS configuration—the socket it proxies the requests to—and the way IIS starts your program agree with each other.
Rework the code to use FastCGI protocol instead.
This basically amounts to using net/fastcgi instead of net/http.
The upside is that IIS (even its dirt-old versions) support FastCGI out of the box.
The downsides are that FastCGI is beleived to be slightly slower than plain HTTP in Go, and that you'll lose the ability to run your program in the standalone mode.
Turn your program into a proper Windows™ service or "wrap" it with some helper tool to make it a Windows™ service.
The former is cleaner as it allows your program to actually be aware of control requests the Windows Service Management subsystem would send to you. You could also easily turn your program into a shrink-wrapped product, if/when needed. You could start with golang.org/x/sys/windows/svc.
The latter may be a bit easier, but YMMV.
If you'd like to explore this way, look for tools like srvany, nssm, winsv etc.
Note that of these, only srvany is provided by Microsoft® and, AFAIK, it's missing since Win7, W2k8, so your best built-in bet might be messing with sc.exe.
In either case, should you pick this route, you'll have to deal with the question of setting up proper permissions on your app's assets.
This question is reasonably complex in itself since there are many moving parts involved.
For a start, you have to make sure your assets are tried to be accessed not from "the process' current directory"—which may be essentially random when it runs as a service—but either from the place the process was explicitly told about when run (via command-line option or whatever) or figured out somehow using a reasonably engeneered guess (and this is a complicated topic in itself).
Next, you either have to make sure the account your Windows™ uses to run your service really has the permissions to access the place your assets are stored in.
Another possibility is to add a dedicated account and make the SCM use it for running your service.
Note that in either case proper error handling and their reporting is paramount: when your program is being run non-interactively, you want to know when something goes wrong: socket failed to be opened or listened on, assets not found, access was denied when trying to open an asset file, and so on—in all these cases you have to 1) handle the error, and 2) report it in a way you can deal with it.
For a non-interactive Windows™ program the best way may be to use the Event Log (say, via golang.org/x/sys/windows/svc/eventlog).
Simplest solutions would be using windows schedular.
Start your exe file on system logon with highest privilage in background. So whenever your system will logon it will start your exe and make runnign in background.
You can refer this answer,
How do I set a Windows scheduled task to run in the background?
Is it better to use mocha with a local server through the grunt-contrib-connect task or just run it with grunt-mocha?
What are the differences/downsides of both?
They are two totally different things. You do not automatically run spec files with grunt-contrib-connect, it is meant to be used in conjunction with other tasks that hit the connect server. You can use it with grunt-mocha (see the urls option), but it's really only useful if you need to test with server logic. Otherwise, you can mock server responses and XHR requests in your tests using sinon.
I have a Sinatra application running on Heroku which makes use of Dalli to enable memcached support. Occasionally, the memcached server fails to respond, and I get the following:
Dalli::RingError - No server available
What is the best way to handle this situation?
I chose to handle this by explicitly ignoring the error, as there is no reason why my app functionality should fail if the caching component is down. You could certainly implement a log statement or whatever you want, but I chose to do nothing.
I created my own Cache class and use that to insulate my domain code from Dalli. Here is the relevant part:
def Cache.get(key)
Configuration.dalliClient.get(key)
rescue Dalli::RingError
nil
end