We've got a plugin that's approved and up on the Office Store, however when a user goes to install the add-on, it consistently fails with a user facing message that says 'We can't perform the operation right now. Please try again later.'
Since the failure's consistent, I looked at the calls that were happening in the storefront, and it appears that this call to service.svc provides the best clue I can find as to why it's failing. I'll paste the response below, but to me it seems the part that seems most relevant is 'This Office Store app can't be installed because it doesn't have a valid digital signature.'
{
"Header": {
"ServerVersionInfo": {
"MajorVersion": 15,
"MinorVersion": 20,
"MajorBuildNumber": 366,
"MinorBuildNumber": 3,
"Version": "V2017_11_14"
}
},
"Body": {
"MessageText": "This Office Store app can't be installed because it doesn't have a valid digital signature.",
"ResponseCode": "ErrorInternalServerError",
"ResponseClass": "Error",
"Extension": null,
"WasFirstInstall": null
}
}
We're having a hard time finding any documentation on how we should go about signing our app or even pointing out that this is a necessary step. If anyone has any experience with this issue where an Office plugin has been approved by MS but won't install for the end user, appreciate any tips.
Also, it may be of use to note that this is an update to an existing application, that contained some manifest changes and some minor JS tweaks, so it's quite likely the fingerprint of the app changed between versions. Thanks in advance for any insight!
The fix would be to bump the version number and resubmit the add-in.
The add-in needs to go through the signing process again and in order for that to happen, it needs to be resubmitted with a higher version number.
Related
I have a bot built in Bot Framework Composer, and I haven't had any issues with adding intents within composer matched to a trigger before.
When I added a new trigger called "SearchWiki" and add utterances, then build the bot, when I test the new trigger, the luis trace returns with "topIntent": "SearchWiki", but the bot executes the actions found in the "Unknown Intent" trigger. This only happens with new intents, as the onther intents I have built still work fine. The only change I can think of that might have affected this is below (note: reverting below changes did not solve the issue)
I recently changed the bot app settings to control the luis app more directly as follows:
FROM:
"environment": "composer",
TO:
"<BOT_NAME>_en_us_lu": {
"appId": "<APP_ID>"
},
Any insight is greatly appreciated.
So while I don't have an exact reason for this, this problem was solved after deleting the following folders from the repository:
./obj/
./bin/
./generated/
I assume that it most likely had to do with the "generated" folder, but if I run into the exact reason I'll document it here for posterity.
I'm trying to use the google api for auto-complete.
I created a key and did some testing, due to an error in my code, that sent many requests in a short time I had the error: OVER_QUERY_LIMIT
I made the correction of my code, deleted the used key and created a new one. Now I get the following message:
{
"error_message" : "The provided API key is expired.",
"predictions" : [],
"status" : "REQUEST_DENIED"
}
Does anyone have any idea how to solve it?
The Message you are getting seems to be very clear.
You could have a licence an this license seems to be exceeded.
Please read the documentation.
The clarity of the message is quite obvious.
The problem is that google warns you that you have a 100k limit available.
The detail is in: these 100k is only available when billing is activated, without activating billing the limit drops to 1.
I would never imagine that.
But it's settled!
The tip is for anyone to go through the same problem
I am trying to upload hosted content for in-app purchases, however I have been unable to succeed so far.
I have previously uploaded around 100 in-app purchases packages for my app using Application Loader. I used to be able to upload these packages before without any issues. Now I’ve noticed that the latest version of Application Loader (Version 3.0) doesn’t even give me the option to upload hosted content (see attached)?
So instead I’ve taken the time to use the iTMSTransporter bash script instead. However when I try to upload the content packs using:
iTMSTransporter -m upload
I am getting the following error:
Package Summary:
1 package(s) were not verified because they had problems:
/Users/Cortana/Documents/iOS/Clients/AccentKit/InAppContent/854413379.itmsp - Error Messages:
ERROR ITMS-90320: "The archive for In-App Purchase 'com.accentkit.AustraliaFemale1' is invalid. The 'IAPProductIdentifier' in the ContentInfo.plist must match the In-App Purchase Product ID."
[2018-04-14 07:12:45 MYT] DBG-X: Returning 1
I’ve double checked and the value for IAPProductIdentifier on the ContentInfo.plist matches exactly with what’s setup on the In-App Purchase Product ID on iTunesConnect. (see attached screenshots) This error is making no sense to me.
Any ideas?
If there was an issue with banking and your sales contract are according to you theoretically back in effect, they may not be effectively back in effect, that is, from Apple's servers point of view.
perhaps this is a process that takes up to a week and the only way to speed it up is to call their technical support.
this is where that'll happen : https://developer.apple.com/support/technical/
I suspect it's likely that your app having been on monetary lockdown at any one point while the bank was an issue may have led into this buggy situation that apple may not have accounted for or that they have accounted for and want you to first go through their IT support process in order for them to first be able to asses that everything is in order.
cheers! :)
I decided to try out Firebase hosting and wanted to start fresh so I deleted my one and only app, but when I tried to create a new app with the same name I was unable to due to the error:
"This Firebase URL is not available"
I can only guess this is because of caching of app names/URLs? Hopefully it will become available (unless someone else beats me to it) after some timeout? Any info from others who have experience with this issue or otherwise know the answer is appreciated!
Not sure whether this is the right place to ask although Firebase suggest coming to SO because they apparently monitor Firebase-related questions closely according to their website.
Thanks!
Once you delete a Firebase URL, it is permanently unavailable. It cannot be recovered.
During confirmation, you should see a message like this, which explains in detail:
This stems from a number of abuse vectors that are possible by misappropriating a project id that the prior owner believes is deleted and could still have apps/releases in the wild attached to the defunct backend. Since compliance requires that we purge all data related to the project, including information about ownership, there's not even a way to restore one you personally deleted.
Generally, I don't ask questions to stackoverflow because I always find an answer by searching. But today, we have a very important problem.
We have somes Drive API issues for a few hours.
A lot of 500 Internal Server Error when we want to take the ownership of a document.
We have tested directly with APIs Playground and it's the same :
https://developers.google.com/drive/v2/reference/permissions/insert
{
"role": "owner",
"type": "user",
"value": "blabla#example.com"
}
The big problem is the API return an error but the take ownership is OK. So Google return to us an error whereas the request is passed correctly...
Does it means we can't trust the API ?
We use Python for this application but we have the same issue for the same request in another application in Java...
Drive is having one of its bad hair weeks. They happen from time to time.
To answer "Does it means we can't trust the API ?", well trust is a bit subjective, but we have started to add defensive coding to our apps. So rather than assume the API is working to spec, we assume it isn't and do a double check.
Eg.after an insert we are now re-fetching the inserted file to confirm that it has been correctly inserted. We also track 304 rate limit errors on inserts because sometimes, despite the exception, the file was inserted. (similar to your observation, except you're seeing 500).