Heroku error when attempting to deploy app from dropbox - express

I am trying to deploy a node app on heroku via the web GUI for dropbox, and I get the error:
Item could not be modified:
"Content-Type" request header must be set to "application/json".
Any clues as to what that might mean?
Disclaimer: I was not the one who wrote the app, just made two mods for heroku.

In case you haven't found an answer... I have the same problem.
You probably need to update your runtime stack.
Here's Heroku's message on their website:
"The legacy Cedar-10 stack has been deprecated and reached its end-of-life on November 4, 2015. Applications may continue running, however you will not be able to push to your application without upgrading to Cedar-14 first."
How to update informations are available here:
https://devcenter.heroku.com/articles/cedar-14-migration#upgrading-the-production-app-to-cedar-14

I have the same problem. I raised a ticket at Heroku. They replied,
"Are you using Firefox? We seen this recently with Firefox and we are currently working on a fix. In the meantime, you can use another browser like Google Chrome for deploying your app."
And using Google Chrome fixes the problem.

Related

"A fatal error occurred while creating a TLS client credential. The internal error state is 10013." every 10 seconds

This has been asked before, but I've been through all the answers provided elsewhere so far, i.e. checking permissions on c:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, adjusting protocols using IISCrypto and turning use of FIPS algorithms on (and off) and I'm still getting batches of 4 events every 10 seconds which swamps the System event log.
I'm running Windows Insider Preview 10 Build 19592.rs_prerelease.200321-1719 (64-bit) so this could be a preview specific issue, however, is there anything else I can try to correct this error?
same issues here, same error code, same pattern , same windows build, tried ISS CRYPTO BEST PRACTICES fix attempt. Did not resolve.
This is not a server, its a standalone client in a home network with no other computers active. Office is not installed, no Exchange, no IIS, no server applications of any kind, just stock windows services. Install is fresh.
Active Browser is Chrome Portable with some basic security plugins such as UBLOCK,Tampermonkey and Adblock. The only webpage opened is this one.
The answer I finally got from a comment on anothersite was that this was a known issue in the Insider Preview and it's now been fixed in the latest releases.
I've gotten this error on an ASP.NET Core 6.0 service that used to work fine previously. The problem turned out to be faulty deployment, that removed all files from the virtual directory.

Error (4800004) authorizing web app

I was debugging my app in my personal Google play services account but the company I am working on has already got their Google play services account so I changed and DELETED (deleting api credentials and unpublished it) the game. I have managed to register a new android app but when I try to register a web app I get the error #4800004 (An unexpected error has occurred. Try again later).
What should I do?
It can take approx 7 days for your old package to be removed. You will not be able to add a new one until that happens.
Your options:
Wait 7 days and try again.
Rename your package.
Alternately: You cannot have two apps with the same package details. Are your two apps conflicting with each other?
From the github post, it was mentioned that you maybe re-registering an app with the same package name. You can check if your project was already registered in the console. Projects that you have deleted will take effect after the 7th day.
For further information, you can also try to check this page. It may also have something to do with SHA1 Signing Certificate Fingerprint from android studio.
You need to make sure that the LaunchURL that you provide includes the protocol (for example: http://) in addition to the domain. If you do not provide the protocol, google appears to automatically add https://, but this led to the error posted in the question for me.

RROR – unable to acquire LMS API, content may not play properly and results may not be recorded. Please contact technical support

We are in the process of implementing Success Factors LMS, and trying to play and view SCORM compatible files exported from Adobe Captivate 8 and 9 in Success Factors LMS.
I get the message - 'ERROR – unable to acquire LMS API, content may not play properly and results may not be recorded. Please contact technical support’
I have tried SCORM versions 1.2 v3 and 2004 V2 and V4. We can view the content, however it does not track, show as complete etc.
We are also producing Scorm compliant files using Skillcast and Articulate, but we still hit the same issue, we can view the content after closing the API error window, but still does not track.
Anyone experienced this problem before? Or know of a fix?
Many thanks
Normally this issue comes up when the course is unable to get the SCORM API from the LMS...I have seen a ton of SCORM content running in Success Factors before, so I wonder if the issue is in the setup. Are you seeing any "Access Denied" type errors in the browser element inspector/developer tools? I wonder if the course just can not find/have access to the player window. If the course is launching in a new window, you may want to try launching it in the frameset. I have seen folks get around this issue by making sure the player and sco are in the same window...
If you wanted to rule out the content being the issue, you can always test your content in the SCORM Cloud's free sandbox (https://cloud.scorm.com) to make sure the course is properly asking for the API...
If you have any other questions, we would be happy to help...you can just shoot us an email at support#scorm.com.
Thank you!
Joe
The error occurs because the content is not speaking to the Learning Management System (LMS). The code that runs to initialize the session doesn't happen. There is no return "ping" from the LMS.
You will get this error when you publish in SCORM and run from your desktop, or from a web server that isn't connected to an LMS. If it occurs when you are launching from an LMS it can either mean that the SCORM API isn't configured correctly, or your content server is on a different domain (cross-domain) than your application servers.
To test, you should try launching your content in different browsers. Our system was configured in such a way that Firefox and Chrome read our content to be cross-domain issue, and threw the SCORM API error, but Internet Explorer worked just fine.
In the end, it was determined that our server configuration in tandem with our firewall and security settings read the Content server as cross-domain and we had to redeploy our content servers within the firewall.

Gmail gadget not refresh although nogadgetcache=1 parameter is used

Problem Description: deployed a new gadget xml but gadget does not refresh although parameter nogadgetcache=1 is used.
Steps to Reproduce:
i makes changes to a gadget xml. Deploy using Eclipse, to an appspot site.
2, Deploy through code.google.com's google app console ( i think this is only for changes to manifest, but with or without this step, refresh does not happen ).
Able to see latest changes on the appspot site hosting the gadget xml
logout of gmail, login with : https://gmail.com/?nogadgetcache=1
gmail gadget behaves like the old version.
Even stopped development for more than a week, still not refreshed.
Anyone here can help or encounter similar issues?
Try renaming the gadget spec file so it uses a new URL (then update your manifest to reflect this new URL). This is from Google's documentation.
we have the same problem it take 30mins to get it work..
https://mail.google.com/mail/u/0/?shva=1#inbox?nogadgetcache=1
i found the problem in chrome take's very long.. if you do it in internet explorer prived mode it much quicker..

No WCF request is sent from Silverlight on client machine

My SL application is commercial and working just fine on hundreds of machines.
SL is using a WCF service and it works as expected, but today I observed behavior on client machine, where literally no call is made to server.
After you click button that sends a call, some error occures, and no record about WCF call is created in Fiddler.
Error is:
[HttpWebRequest_WebException_RemoteServer]
Arguments: NotFound
Debugging resource strings are unavailable...
I read about this error that people recommend to use Fiddler, but as I say there is no call displayed in Fiddler
So problem is worse than I thought initially.
It comes and goes. Currently we have found a working solution that fixes the problem after it appears although it doesn't make any sense to me.
For example if I get this error in chrome & mozilla & OOB version,
launching a program in IE works, and after that chrome,mozilla & OOB
start to work too.
Thing is that same people who had this problem solved with this workaround experience it again in some days, like a week, with no apparent reason, and then combination of launches from various locations helps (usually IE helps the most).
Any help appreciated, I start a bounty as its pretty sick bug and I need to fix it somehow.
Update
Weird IE fix scenario:
At some point OOB version gets into state where it doesn't send any WCF request to server.
(fiddler doesn't see it, server doesn't gets it).
After launching web version in IE, and hitting the same button, that sends WCF request we get desired result in IE web version.
Without changing anything else, just relaunching OOB version which was in this buggest state before, makes OOB version work correctly. Its not reinstalled, not changed - nothing.
This is what I call "IE cure" of this problem.
So the question is what can IE launch potentiall change for OOB version?
According to this thread the message Debugging resources are unavailable appears when de client is not using the the Silverlight Developer Runtime.
This means that the actual exception is hidden from you (and us) so the next step is to reproduce the error on a system that has the Silverlight Developer Runtime.
I found this article. It might be worth it to check the certificate you are using (are you using a certificate) It is one of those things that is different with OOB apps and browsers.