Registering the same device with the same tags and template results in multiple identical registrations in the hub.
Will this cause a problem and will Azure eventually remove them?
It doesn't seem to result in duplicate messages sent to a device.
I figure I can limit duplicate registrations by checking to see if they exist first using GetRegistrationsByTagAsync.
Even that method only takes one tag, so it's then typically necessary to iterate over all the tags for each registration to complete a match. Plus, the device token needs to be added as a tag because the registration base class doesn't have a "token" property. (EDIT: Actually, that doesn't work because it says the token is an invalid tag. So I'm going for one installation per platform - perhaps I could switch on the installation's class type to get the token value.)
Honestly, this API seems somewhat half baked. Even the newer installation based part of the API doesn't even let you download all the installations so you have to have some way of keeping track of them if you want to update them. If you have to keep a copy of this data then you may as well skip Azure altogether.
You can get the installations from the Azure tab in Visual Studio but once deleted, it doesn't seem possible to reinstall a device.
What a mess.
Related
I work in a company where we have many different applications. To reduce code repetition and keep the experience for the users the same across applications we created a component library which is used by all applications.
Now we want to allow the users to switch between applications. Something similar like Google does:
Screenshot of Google Application Drawer
An additional requirement for our "Application Switcher" would be that it "updates" itself. Meaning if we change how this "Application Switcher" looks we don't want all applications which use this Switcher to create a new deployment and be newly deployed.
So currently we use the same header (from our component library) in all our applications. So, my idea was just to simply add a script tag to all the index.html pages of all the applications which should support this "Application Switcher". The Script would parse the DOM, find the header and inject a component for this application switcher. I wanted to host the actual script from a CDN like server and the script tag in the index.html just references this URL. This way we could change this script however we want, and all the applications will always get the latest version.
Now I did a small proof of concept in our environments and solved all the CORS issues but since we were fetching from an authenticated context and the script was also in an authenticated context I always got a 401.
Additionally, we have the requirement, that this "Application Switcher" shows different applications to different users i.e. depending on which apps a user is allowed to access. So, the script itself will also do calls to an "Application Switcher" backend providing it user-specific information.
Now this makes me think that my initial idea of just putting a script tag and fetching from a CDN was too simplistic. Now I'm thinking if it would be better to implement a rest endpoint in all applications to fetch this script. This way I don't have the problems of fetching a resource from an authenticated context from the user's browser and instead can handle all of this in the backend.
So long story short; I feel like a complete noob who just hacks around to get things working (or actually not working) and was wondering if any of the smart internet people out there (who might actually already have experience with this) could give me a hint what would be a clean way to implement this?
I am dual-posting this here while I wait for DocuSign support to get around to assisting in the hopes someone here has some more insight.
Our application uses the DocuSignConnect API to manage brands. It has been in production for years and worked without issues. Sometime last week, our API calls to create brands began failing, but only on the Demo system. This functionality is continuing to work fine in the Production system. There are no code differences between our Demo and Prod environments.
In the past, we have seen issues (of a different kind) when changes are rolled out to the DocuSign Demo system. I wonder if this could be one of those scenarios.
The details are limited. Our API calls to create a brand are met with a failure with the following properties:
ErrorCode: 309
ErrorReason: Brands could not be created.
faultString: Brands could not be created. Unable to upload brand, error: Must specify valid information for parsing in the string.
As I mentioned above, our application has not changed recently with respect to the DocuSignConnect API. I have noticed, however, that the Signing and Email resource xml files appear to be undergoing a change (they differ significantly between DocuSign's Prod and Demo sites.) Perhaps this is a clue behind the fairly unhelpful "...specify valid information for parsing..." message.
My concern is that something is soon to be deployed to Production that will break our application.
I should add that our other API calls seem to be ok (sending envelopes, for example)
Has anyone experienced this type of problem creating brands?
The update on this from DocuSign support is that the 'type' attribute on the 'logo' element that is part of the XML schema defined in the 'CreateBrand' API call has changed from optional (in their PROD environment) to required (in their DEMO environment).
They are probably going to be changing their DEMO code to revert this attribute back to 'optional' before it is deployed to their PROD system.
But in any event, our code is going to change to start including the 'type' attribute on the 'logo' elements to ensure success going forward regardless.
I am working on a little project that I would allow me to update the location of a food truck that moves often.
I know there are apps that one could download but I'm hoping to avoid telling people to download ANOTHER app to keep up, instead it would be awesome to just have it searchable on google maps and have GPS directions to the truck available.
I see that the places API allows adding and deleting of places, I'm not sure how long that takes to update but I will figure that out once I can actually add a place.
Has anyone been able to succesfully do anything like this before with node? I understand that the javascript API will not do add requests so it seems node is the best solution here.
If you look at the places API, Google said:
When you add a place, the new place is available immediately in Nearby Searches initiated by your application. The new place also enters a moderation queue to be considered for Google Maps.
So your truck won't be visible on the Google Maps until after Google Maps decided to add it. But more than this, if you look at the deleting section:
A place can only be deleted if:
*The place was added by the application that is requesting the
deletion.
*The place add request has not successfully passed through
the Google Maps moderation process, and the place is therefore visible
only to the application that added it.
Which is, in other words, you would not able to update its position ever again after they approved your location.
In stead, you should use the Javascript API to make your own webapp, to get something like this http://planefinder.net/flight/CPA872
UPDATE
Unfortunately, Place Add has been deprecated on June 30, 2017 and will stop working on June 30, 2018. So you cannot use this method anymore. For further details please refer to the corresponding geo blog post.
I'm trying to develop a site, where users will be registered directly on it, as opposed to being authenticated by Google mail etc. Beside the usual username/password I need to collect more data from the user - name, address, etc. What would be the quickest way for adding the desired functionality? Short of writing my own Auth plugin I see two options:
Create my own registration form (which I kinda need to do anyway) and use HashDB for storing the passwords and later authentication. However, yesod.auth.hashdb seems to be gone from the latest version (why?) and is only available separately here: https://github.com/ollieh/yesod-auth-bcrypt/ . Is something wrong with it? Security flaws?
Use http://hackage.haskell.org/package/yesod-auth-account - looks much closer to what I need, because it already provides registration page, but it doesn't seem to be supported by the latest yesod 1.2.5 and it is not clear how to integrate my additional fields into the existing registration process
I have a plugin that is triggered every time when an account entity is updated. I also have a workflow that updates the account when an opportunity is closed as won.
Plugin works well when I'm in the account form and hit the save button. Workflow works well too except that when it's updating the account my plugin is not triggered even when it should be(?).
Any ideas?
I faced a similar kind of situation as yours, where I had a depth checking enabled in the plugin code. Workflows updating the entity has a depth of 3, which will get bypassed if you have that checking of 1 inside the plugin code.
Not sure if you have a similar issue here, since you're saying it's managed code and you dont have access to it. Is it some kind of package that you bought/downloaded; or will it be possible to get your hands on the code?
You should also check if the plug-in is triggered for specific attributes. If so ensure the your wf also updates these attributes so the plug-in is triggered.
Also, the code might be targeting caller origin and denying access from async service. you need to pick under the hood to gain better insight.