Can we have a sample of variables available for redefinition of templates, documentation is scarce on this?
In Class package de.codecentric.boot.admin.notify.MailNotifier I read
private static final String DEFAULT_SUBJECT = "#{application.name} (#{application.id}) is #{to.status}";
private static final String DEFAULT_TEXT = "#{application.name} (#{application.id})\nstatus changed from #{from.status} to #{to.status}\n\n#{application.healthUrl}";
In my specific use case I inherited a bunch of applications which I want to ping or monitor they are alive. I have no control on them but my app depends on them.
My app doesn't fail but may misbehave (important point!).
So I added a bunch of customs HealthIndicator to get them monitored by ping, that work perfectly, and I was very pleased by changing an IP a notification was sent, great!
But there is a but, the message sent let me think than the app was failing, while instead the health indicator was status OUT_OF_SERVICE, unnecessary stress for DevOps.
Come to my question, how can I add some extra variables whereby some carefully crafted SPEL will distinguish an Health indicator message status change than an application status change ie webapp going offline.
Is a dictionary of SBA keywords available to use for redefining for example spring.boot.admin.notify.mail.text Mail notifications configuration option?
I guess this is valid to other notifiers being hipchat, Slack.
Thank you.
The context for evaluating the SpEL expression is the event.
Therefore all properties from ClientApplicationEvent (or the corresponding subclass for the event instance (e.g. ClientApplicationStatusChangedEvent)) are available.
If it doesn't suffice you can ship your own subclass of the MailNotifier..
Answer is no, cannot do in current code base without code changes.
SBA notification keywords/variables available are the following:
application.name
application.id
application.healthUrl
application.managementUrl
application.serviceUrl
application.statusInfo.status
from.status
to.status
timestamp
type
We don't have anything else.
However the StatusUpdater.queryStatus looks promising to get some extra data.
Related
I'd like to protect against unauthorised system extension teardown that are triggered by
the container application following this command:
self.deactivationRequest =
OSSystemExtensionRequest.deactivationRequest(
forExtensionWithIdentifier: extensionIdentifier, queue: .main)
self.deactivationRequest!.delegate = self
OSSystemExtensionManager.shared.submitRequest(self.deactivationRequest!)
Is there a callback in the endpoint extension code, that can be invoked upon this deactivation request, and may block/allow it ?
thanks
There is no public API to control the system extension deactivation with EndpointSecurity or inside sysext itself (activation and deactivation management, I think, is a job for some daemon, like sysextd).
I could advice to try two approaches for your case:
You may still be able to deny deactivation with EndpointSecurity, just not in direct way. To deactivate sysext the responsible processes would do a lot of stuff, including opening some specific files, reading them, etc. In case you are lucky, you may be able to fail the deactivation process by blocking one of such operations before it really deativated. However, the context of operation (how do you know the target is your extension) may vary and be less than you need.
You may intercept the OSSystemExtensionManager.shared.submitRequest call inside your application, and add some condition to really call original method from interception method. The interception for submitRequest will be a swizzling.
Or you can place an old good hook on something deeper, like xpc_* stuff, and filter your deactivation request by some unique string from request, also calling original method only on some condition.
Both ways are not bulletproof from perspective of tampering protection ofc, but nothing really is, we just requesting additional efforts from hacker.
If you haven't disabled library validation for your app, there are two ways of tampering it: either turning SIP off, or using some 0-day system breach.
You can't really protect your app from such treats: 0-days are new, you don't know what it may be, and with SIP off the one may unload/disable/alter all possible kinds of protection stuff.
Background
On Android, there are 2 possible ways to listen to system events via BroadcastReceivers :
statically, via the manifest
programmatically, via the code.
Since some projects contain a lot of activities, services, and "manager"-classes , it could be useful to have a single BroadcastReceiver that will notify all of its listeners on the app about what has happened, instead of having multiple BroadcastReceivers being used (and their code handling).
An example of such a BroadcastReceiver, is the one that listens to the connectivity changes:
#Override
public void onCreate() {
super.onCreate();
...
registerReceiver(new ConnectivityChangedBroadcastReceiver(), new IntentFilter(
ConnectivityManager.CONNECTIVITY_ACTION));
...
}
The question
The purpose is to listen to the events while the app is "alive" (by services and/or activities) .
Using the manifest would miss this purpose, as it will wake the app each time the event occurs, even if the app doesn't need it.
Thing is, unregistering doesn't occur, and maybe it causes the OS treat the app in a different way because of it.
Does having a call to "registerReceiver" on the class that extends from Application is a good known practice?
Does it have any side effects and things to know about when using it?
Is there any alternative to this?
I just want to be sure it's considered safe to use.
we can't really know what is good or better for you.
I advise you to learn more about the difference between the registration ways of the receiver:
1/ in the manifest :
the handler of the receiver will be triggered each time that the correspondent event comes. Example: the messenger of facebook is lunched every time that you have internet connection to show you your notifications... or other applications are lunched when you connect to propose updates ...
in other words, the receiver is always registered.
2/ in a service or an activity or an application :
the receiver will be unregistered when the context of where it is registered is killed.
in other words, it depends totally of the context where it is registred , and you are obliged to unregister it somewhere in the code. exemple : one activity is waiting that a service ( which is doing something in the background) sends an alert to update something , then you can register the receiver in your onResume() and unregester it in your onPause().
Conclusion : It depends only in the life-cycle requirement of the receiver.
see also Broadcast Receiver Register in Manifest vs. Activity
Main difference between Manifest and Programmatic registering of BroadcastReceiver
I've got a Backbone web application that talks to a RESTful PHP server. For PUT and POST it matters in which order the requests arrive at the server and for GET it matters in which order the responses arrive at the client.
The web application does not need to be used concurrently by multiple users, but what might happen is that the user changes its name twice really fast. Then the order in which the server processes PUT /name/Ann and PUT /name/Bea determines whether the name is set to Ann or Bea.
Backbone.Safesync and Backbone.Sync.AjaxQueue are two libraries that try to solve this problem. Doesn't Safesync only solve the problem with GET? Sync.AjaxQueue is outdated, but might serve as inspiration to implement a custom queued sync function. Making sync synchronous would solve the problem. If a request is only sent after the previous response is received, then only one request is processed at a time.
Any advice on how to proceed?
BTW: I don't think using PATCH requests would solve anything, because in my example the same attribute is changed twice.
There's a few ways to solve this, here's two:
add a timestamp to all requests, store it in the DB as "modified" and let the server check whether the timestamp of the new request is later than the one in the DB in order to be valid
use Promises to delay the second request from being made before the first one is responded on, there's a promise/deferred mechanism built into jquery, but you can also use a 3rd party one, for instance Q or when
If you can afford the delay, an easy approach is to set the async option to false when you call whatever method you're calling that results in the Backbone.sync. For example, in the appropriate model(s) simply override the default sync method to include the additional option.
I cannot find anywhere how to manage custom U-type messages. I use MessageCracker and need to understand the corresponding OnMessage method signature. For example my broker sends custom U1,U5, U2 messages, how can I capture those incoming messages inside a OnMessage method? I understand that Tag35 identifies those but if I cannot capture them through OnMessage then MessageCracker becomes kind of useless and I need to identify each message by Tag35 within FromApp or FromAdmin. Any suggestion how to handle those kind of custom U-types?
Thanks
Ah, custom messages. Fun stuff.
You need to add your counterparty's customizations to the DataDictionary xml file. Choose the appropriate FIXnn.xml file for your FIX version.
See here: http://quickfixn.org/tutorial/custom-fields-groups-and-messages
Then, because you are adding custom messages, you'll want to regenerate the QF/n source and rebuild the library so you can get classes for your new messages.
Instructions for rebuilding are here: https://github.com/connamara/quickfixn
You'll need to install Ruby. This annoys some people, but we haven't found any more-windows-oriented code-generator that we don't hate. Sorry in advance.
(If you were just adding fields to existing messages, you could probably get away with not rebuilding. But you're adding messages, so you pretty much have to regenerate/rebuild.)
To Windows developers, it may seem annoying that rebuilding the library is required, but it really is the norm for all the QF engines. FIX is just too fudgey a protocol for a single build to satisfy everyone, because it seems that every counterparty likes to screw with the message definitions.
I want to implement the feature "DO Not Disturb" in iOS 6.
First question : Is there any framework or api apple exposed to control them through the code?
After lot of googling i found an application on the app store "Call Bliss" that provides this functionality and complete control over the calls, sms and mms.
Can anybody explain how this application works?
or
any other work around to learn and implement this feature in iOS?
Thanks in advance...
From reading the description of Call Bliss, it actually sounds quite simple in how it works.
1) Do Not Disturb must be enabled at all times. Not scheduled, not off, but on at all times.
2) It requires you to set the contacts group for exceptions to Do Not Disturb to "Bliss Exceptions". This implies that the application requires access to your address book.
From there, it's probably wise to assume that it manages the contacts in the "Bliss Exceptions" contact group based on whatever parameters you set in the application. It adds and removes people in that group based said parameters.
So to answer your question, no, there is no framework to do this. The way they're doing it is likely the only way to do it currently with no public API for managing do not disturb status.
There is no public API to even access do-not-disturb functionality.
I think this is what the app does:
The app creates and manages its own contact list (called Bliss exceptions)
the user have to select it in the do-not-disturb preferences.
The App can run in the background because it uses location tracking (probably significant only to save battery life), so when the user changes locations it can update the exception list.
When a call is received do-not-disturb system functionality checks the Bliss exceptions list and silences all calls from contacts on the list.
Please note that reviewers complain about the lack of time based call blocking. It is impossible because the app can only execute code when the location is changed.
In my Knowledge there is no way to implement it via code. There is no public api provided for restricting the calls.
But there is an API for detecting the calls : CTCallCenter and a FrameWork called CoreTelephonyFramework