apigee-access provides a way for KVMs to be accessed under node.js via javascript:
var kvm = apigee.getKeyValueMap('kvm_name', 'scope');
Are there any similar functionalities available from within a javascript policy? In my usage scenario I'd like to access arbitrarily defined keys from a known KVM.
Related
Since AppCenter retiring at the end of this year, I have started migrating to Azure-Notification-Hub.
But the documentation for notification-hub is not clear at all. Especially the documentation for Xamarin.Android. It does not match with their latest SDK.
In the latest (version 1.1.1) azure-notification-hub SDK for Android (or Xamarin.Android) there's no need to implement FirebaseMessagingService. NotificationHub.Start() method registers the device in the Notification-Hub. A device registered with this way gets notifications without any problem.
NotificationHub.Start(Application, <HubName>, <ConnectionString>);
Addition tags to existing NotificationHub instance are also straightforward with the new SDK.
NotificationHub.AddTag("username:user123");
But in Registration Management official doc states that devices can register with the notification-hub either from client-side or from server-side. Is it necessary to use one of those methods if my app registered with the notification-hub using the NotificationHub.Start() method? Or do I missing something?
Also, when I was using the AppCenter, I have used the AppCenter-InstallId to target a specific device.
With that in mind is it possible to use the NotificationHub.InstallationId to use as a tag (eg: "handle:<devce's InstallationId>") to send device-specific notifications?
Is it necessary to use one of those methods if my app registered with the notification-hub using the NotificationHub.Start() method?
When you invoke NotificationHub.start(Application, ...), the Android SDK will listen for changes like added tags, new FirebaseMessagingService tokens, etc. Anytime it detects a change, it will invoke an InstallationAdapter to inform a backend of the new details.
The default InstallationAdapter will send an PUT request to the Azure Notification Hubs backend as documented here. This is what is created by NotificationHub.start(Application, string, string); for people who are not hosting their own backend, this is a sensible default.
If you have your own backend where you track devices, or you're just looking to keep your credentials server-side, you can swap out the InstallationAdapter to be a class that invokes your API. All you need to do is implement the InstallationAdapter interface and initialize the SDK by calling NotificationHub.start(Application, InstallationAdapter).
If you use the NotificationHub.start(...) methods as indicated above, there is no further registration action required.
With that in mind is it possible to use the NotificationHub.InstallationId to use as a tag (eg: "handle:<devce's InstallationId>") to send device-specific notifications?
Yes! This documentation walks you through how to use the special tag format $InstallationId:{YOUR_TAG_ID} to target a specific device.
When you've used NotificationHub.start(), if you do not specify an InstallationId, it will generate one for you.
Question about setting the InstallationId and/or UserId. If I'm using Microsoft.Azure.NotificationHubs.Client, which makes more sense to do.
Should I set the InstallationId via the $InstallationId Tag (see here: https://learn.microsoft.com/en-us/azure/notification-hubs/notification-hubs-push-notification-registration-management#installations) or via implementing the InstallationEnrichmentAdapter and set it via a call to installation.InstallationId = in the EnrichInstallation method?
Additionally, the Microsoft.Azure.NotificationHubs.Client.Installation class provides a UserId property that can be updated too.
I'm also moving my push notifications from AppCenter to Azure Notification Hub and want to reuse my existing AppCenter InstallId.
i am able to add tags and userid as below(java)
NotificationHub.start(this.getApplication(), BuildConfig.hubName, BuildConfig.hubListenConnectionString);
NotificationHub.setInstallationId("123");
Set<String> tags = new HashSet<>();
tags.add("role_memeber");
NotificationHub.setUserId("123");
NotificationHub.addTags(tags);
sdk: com.microsoft.azure:notification-hubs-android-sdk:1.1.6
We have a microservice that needs to be integration tested (real calls, but no network communication with anything outside of the test namespace in kubernetes) in our pipeline. It also relies on an external gRPC server which we have no control over.
Above is a picture of what we'd like to have happen. The white box on the left is code that provides the Microservice Boundary with 'external' data. It then keeps calling the Code via REST until it gets back the proper number of records or it times out. The Code pulls records from an internal database, as well as data associated to those records from a gRPC call. Since we do not own the gRPC service, but are doing integration tests, we need a few pre-defined responses to the two gRPC services we call (blue box).
Since our integration tests are self-contained right now, and we don't want to write an entirely new actual gRPC server implementation just to mimick calls, is there a way to stand up a real gRPC server and configure it to return responses? The request is pretty much like a mock setup, except with an actual server.
We need to be able to:
give the server multiple proto files to interpret and have it expose those as endpoints. Proto files must be able to have different package names
using files we can store in source control, configure the responses to each call
able to run in a linux docker container (no windows)
I did find gripmock which seemed almost exactly what we need, but it only serves one proto file per container. It supposedly can serve more than one, but I can't get it to work and their example that serves two files implies each proto file must have the same package name which will likely never happen with our scenarios. In the meantime we are using it, but if we have 10 gRPC call dependencies, we now have to run 10 gripmock servers.
Wikipedia contains a list of API mocking tools. Looking at that list today there is a commercial tool that supports gRPC called Traffic Parrot which allows you to create gRPC mocks based on your Proto files. You can give it multiple proto files, store the mocks in Git and run the tool in Docker.
There are also open-source tools like GripMock but it does not generate stubs based on Proto files, you have to create them manually. Also, the project up to today was not keeping up to date with Proto and gRPC developments i.e. the package name issue you have discovered yourself above (works only if the package names in different proto files are the same). There are a few other open-source tools like grpc-wiremock, grpc-mock or bloomrpc-mock but they still lack widespread adoption and hence might be risky to adopt for an important enterprise project.
Keep in mind, the mock generated will be only a test double, it will not replicate the full behaviour of the system the Proto file corresponds to. If you wanted to also replicate partially the semantics of the messages consider doing a recording of the gRPC messages to create the mocks, that way you can see the sample data as well.
Take a look at this JS library which hopefully does what you need:
https://github.com/alenon/grpc-mock-server
Usage example:
private static readonly PROTO_PATH: string = __dirname + "example.proto";
private static readonly PKG_NAME: string = "com.alenon.example";
private static readonly SERVICE_NAME: string = "ExampleService";
...
const implementations = {
ex1: (call: any, callback: any) => {
const response: any =
new this.proto.ExampleResponse.constructor({msg: "the response message"});
callback(null, response);
},
};
this.server.addService(PROTO_PATH, PKG_NAME, SERVICE_NAME, implementations);
this.server.start();
I was working on a project which required me to create Keyvault reference in azure AppConfiguration, add/update secrets in KeyVault and to access values in AppConfiguration using Configuration.
Currently, I'm using :
-ConfigurationClient to create key Vault reference.
-SecretClient to add/update secrets in KeyVault.
-Configuration build using the builder.AddAzureAppConfiguration().build() to access values in AppConfiguration.(using builder.AddAzureAppConfiguration() is a necessity due to its features).
So, basically 3 connections to azure are made here. Is there any way to decrease the no. of connections? Like, using the ConfigurationBuilder to get a ConfigurationClient and/or SecretClient.
Since your application is accessing two different resources, App Configuration and Key Vault, a minimum of two connections are needed. This is due to lack of support for shared connections across different services.
Assuming your application is using ConfigureKeyVault to access Key Vault references, the call to AddAzureAppConfiguration().Build() is actually creating two connections - one to App Configuration and the other to Key Vault. In this case, there are a total of 4 connections. You can reduce it to 3 by registering the SecretClient you created to add/update secrets in Key Vault in the AddAzureAppConfiguration method.
SecretClient secretClient = new SecretClient(new Uri("http://my-keyvault-uri"), new DefaultAzureCredential());
builder.AddAzureAppConfiguration(options =>
{
options.Connect(settings["connection_string"])
.ConfigureKeyVault(kv => kv.Register(secretClient));
});
At this time, there isn't a supported way to provide an existing instance of ConfigurationClient while setting up the AddAzureAppConfiguration method, but this may be supported in the future.
In vSphere web client extension development , i want to fetch the properties of VM , In the sample code model they are adding some annotations like
[Model(property="name")]
/**
* The name of this VirtualMachine.
*/
public var name:String;
Where can i get the List of available properties for all objects (like vm , datastore , hosts)
Presuming that you're talking about building an extension for the vSphere 5.1 web client, the documentation has a list of extension points. Listing the properties for each type of object would be far outside the scope of an answer here, so I'll instead point you to the vSphere 5.1 SDK documentation, specifically the appendix listing all properties.
If you're new to vSphere web client extension development, a good starting point is the What’s New In vSphere 5.1 API, vSphere Web Client SDK & vCenter SSO SDK blog post. I see that you've already posted the same question in the VMware Communities, so I don't need to point you there.
The properties correspond to the properties of Managed and Data Objects as described in the vSphere Managment SDK documentation. In particular the example you gave corresponds to Managed Object VirtualMachine's name property. Since VirtualMachine inherits from ManagedEntity, this is where the name property is actually defined (see http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.wssdk.apiref.doc%2Fvim.ManagedEntity.html for details). You can also use property.paths.into.data.objects to access properties of nested data objects.
If you want to get list of vm or datastore... you can use DataServiceProvider get data with a simple constraint
I don't want just all of my users being able to insert/destroy data.
While there is no documented way to do this yet, here's some code that should do what you want:
Foo = new Meteor.Collection("foo");
...
if (Meteor.is_server) {
Meteor.startup(function () {
Meteor.default_server.method_handlers['/foo/insert'] = function () {};
Meteor.default_server.method_handlers['/foo/update'] = function () {};
Meteor.default_server.method_handlers['/foo/remove'] = function () {};
});
}
This will disable the default insert/update/remove methods. Clients can try to insert into the database, but the server will do nothing, and the client will notice and remove the locally created item when the server responds.
insert/update/remove will still work on the server. You'll need to make methods with Meteor.methods that run on the server to accomplish any database writes.
All of this will change when the authentication branch lands. Once that happens, you'll be able to provide validators to inspect and authorize database writes on the server. Here's a little more detail: http://news.ycombinator.com/item?id=3825063
[UPDATE] There is now an official and documented Auth Package which provides different solutions to secure a collection.
On a CRUD level :
[Server] collection.allow(options) and collection.deny(options). Restricts default write methods on this collection. Once either of these are called on a collection, all write methods on that collection are restricted regardless of the insecure package.
And there is also insecureto remove full write access from the client.
source : Getting Started with Auth (thanks to #dan-dascalescu)
[OLD ANSWER]
Apparently there are working on Auth Package(?) that should avoid any users taking full control on the db as it is now. There is also someone suggesting that there is an existing solution (workaround) by defining your own mutations (methods) and make them failed if they attempts to perform an unauthorized action. I didn't get it much better but I think this will often be necessary since I doubt the Auth Package will let you implement the usual auth logic on a row level but probably only on the CRUD methods. Will have to see what the devs have to say.
[EDIT]
Found something that seems to confirm my thoughts :
Currently the client is given full write access to the collection. They can execute arbitrary Mongo update commands. Once we build authentication, you will be able to limit the client's direct access to insert, update, and remove. We are also considering validators and other ORM-like functionality.
Sources of this answer :
Accessing to DB at client side as in server side with meteor
https://stackoverflow.com/questions/10100813/data-validation-and-security-in-meteor/10101516#10101516
A more succinct way:
_.each(['collection1', 'collection2'], function(collection){
_.each(['insert','update', 'remove'], function(method){
Meteor.default_server.method_handlers['/' + collection + '/' + method] = function(){}
});
});
or to make it more idiomatic:
extend meteor:
_.extend(Meteor.Collection.prototype, {
remove_client_access: function(methods){
var self = this;
if(!methods) methods = ['insert','update','remove'];
if(typeof methods === 'String') methods = [methods];
_.each(methods, function(method){
Meteor.default_server.method_handlers[self._prefix + method] = function(){}
});
}
});
Calls are simpler:
List.remove_client_access() // restrict all
List.remove_client_access('remove') //restrict one
List.remove_client_access(['remove','update']) //restrict more than one
I am new to Meteor, but what I have come across so far are these two points
You can limit what a client can access in the database by adding parameters to the find command in the server-side publish command. Then when the client calls Collection.find({}), the results that are returned correspond to what on the server side would be, for example, Collection.find({user: this.userId}) (see also Publish certain information for Meteor.users and more information for Meteor.user and http://docs.meteor.com/#meteor_publish)
One thing that is built in (I have meteor 0.5.9) is that the client can only update items by id, not using selectors. An error is logged to console on the client if there is an attempt that doesn't comply. 403: "Not permitted. Untrusted code may only update documents by ID." (see Understanding "Not permitted. Untrusted code may only update documents by ID." Meteor error).
In view of number 2, you need to use Meteor.methods on the server side to make remote procedure calls available to the client with Meteor.call.