For the past 12 or so hours when I go here:
https://console.developers.google.com/apis/credentials?project=MYPROJECTNAME
I just get the spinning / loading animation. I have tried other browsers and other computers to no avail. I just need to add another OATH key. Is the service somehow broken? Is there something else I can do?
The browser shows some errors.
Refused to display 'https://apikeys.clients6.google.com/static/proxy.html?usegapi=1&js [ stuff deleted] in a frame because it set 'X-Frame-Options' to 'sameorigin'.
and a few 404s
cloudusersettings-pa.clients6.google.com/v1alpha1/settings/PAN_NOTIFICATION_BELL_LAST_OPENED?key=[deleted]:1 Failed to load resource: the server responded with a status of 404 ()
like it's able to load the front end but not access the data it needs.
Sounds like it's a Google issue, just got a response back from Google:
Description:
We are experiencing elevated latency in the API Credentials page of Google
Developers Console beginning at 2019-02-09 20:06 PST.
We are using the external issue tracker as the main communication channel
to provide updates on this issue. Please star the issue here to receive
further updates: https://issuetracker.google.com/124188941.
This Issue Tracker entry is the authoritative source for public information
regarding this issue. All publicly-applicable updates will be posted there.
How to diagnose:
1. Visit Google Developers Console.
2. Select "APIs & Services".
3. Select "Credentials".
Result: Credentials page will continuously load.
Workaround:
There's no workaround available at this time, but we'll let you know via
the external issue tracker (https://issuetracker.google.com/124188941) if
we learn of one.
Related
I'm getting the following error on the Ohio server:
Failed to authenticate user due to missing information in request.
This suddenly started happening after using Glue for few months.
Error picture here
I've tried adding AWS onto my cookie allow list and still doesn't allow me. I've also tried restarting my machine and using another 2 browsers other than chrome yet still doesn't work. I'm the only one affected on the team it only happens on the Ohio server whilst NV etc work perfectly.
I had the exact same issue. Check that your browser does not block third-party cookies. Any browser that blocks third-party cookies either by default or as a user-enabled setting will prevent notebooks from launching (the typical error message is Failed to authenticate user due to missing information in the request.)
Chrome: Turn Off "Block Third-Party Cookies" in Chrome for Windows
Firefox: Third-party cookies and Firefox tracking protection
Safari: Clear cookies in Safari on Mac
How do I get a registration code or otherwise solve this problem?
While writing this question, I realized the crux of this problem is the bottom-most part of this question: I'm not getting the popup I'm supposed to get and when I enter the URL in a browser it says invalid registration code.
I'm attempting to develop an Alexa Voice Service application. Website/companion service only. I have gone through the Reference Implementation Guide twice and have double checked that all of the setup has been done correctly.
This is the server error I get: invalid registration code. I never did anything with a registration code and can't seem to find anything about a registration code (relevant to Alexa) anywhere after googling quite a bit.
Listening on port 3000
error: { [InvalidRegistrationCode: The provided registration code was invalid.]
name: 'InvalidRegistrationCode',
message: 'The provided registration code was invalid.',
status: 401 }
Error: Can't set headers after they are sent.
Here's the client output:
vlcj: (DefaultMediaPlayer.java:183)
addMediaPlayerEventListener(listener=com.amazon.alexa.avs.AVSAudioPlayer$1#4b3a4950)
There was a problem connecting to the Companion Service. Trying again in 2 seconds. Please make sure it is up and running.
[DEBUG] joining on thread Thread[Timer-0,5,com.amazon.alexa.avs.AVSApp]
There was a problem connecting to the Companion Service.
Trying again in 2 seconds. Please make sure it is up and running.
The AVS launcher opens too, and when I record something and send it I get:
com.amazon.alexa.avs.AVSException: 403 Invalid Access Token
The instructions mention (at the very bottom of the reference guide) that I need to:
Please register your device by visiting the following website on any system and following the instructions: https://localhost:3000/provision/************** That URL is supposed to pop something up once the companion service but that hasn't happened.
Any thoughts on how can I fix this?
I was following a good document Project: Raspberry Pi + Alexa Voice Service at https://github.com/amzn/alexa-avs-raspberry-pi . It describes all steps very well.
Please take a look at the following steps:
3 - Getting started with Alexa Voice Service
3.1 Register for a free Amazon Developer Account
3.4 Register your product and create a security profile.
6 - Enable Security Profile
This thread on the Amazon developer forums seems related: http://forums.developer.amazon.com/forums/thread.jspa?threadID=11327&tstart=0
Quoted response:
There are a number of potential issues causing that error.
You might be sending an invalid scope. Are you sending "alexa:all" as
the scope? Or, your security profile might not be correctly linked. Is
it selected in the dropdown on the developer portal?
Are you getting an access token from the companion service, or is the
text box blank? If you're not getting an access token, check that your
device serial number matches between the companion service and the
java client. If you're getting an access token, the problem is more
likely with your security profile.
You should also look at these threads to see if they're helpful...
(links removed due to reputation requirement)
If that doesn't help, you'll probably have more luck asking the AVS team directly on their forum site.
I'm evaluating WSO2 Identity Server 5.0.0 but I'm getting a strange issue using the dashboard.
I installed it on a server of mine (so it is not on localhost) and configured the following configuration files so that WSO2 knows where to point
File wso2is-5.0.0/repository/conf/carbon.xml
<HostName>SERVER_IP</HostName>
<MgtHostName>SERVER_IP</MgtHostName>
File wso2is-5.0.0/repository/conf/security/saml2.federation.properties
WSO2=https://SERVER_IP:9445/samlsso
File wso2is-5.0.0/repository/conf/security/sso-idp-config.xml
<SSOIdentityProviderConfig>
<ServiceProviders>
<ServiceProvider>
<Issuer>wso2.my.dashboard</Issuer>
<AssertionConsumerService>https://SERVER_IP:9443/dashboard/acs</AssertionConsumerService>
...
As stated in the official documentation I should see some blocks and after clicking the "View details" buttons I should be able to do the operations of the dashboard related to each block.
However, when I login in the Dashboard I can see the blocks, but when I click "View details" I get a blank-content page a you can see in the following screenshot of the "My Profiles" page
The same thing happens for the other blocks.
What can I do? Maybe I didn't configure something?
Thank you in advance
Giulio
If you have installed the identity server other than localhost, You would see some issues with dashboard. I also experienced same type of issues. But you can resolve them by configuring the host name and port properly. Unfortunately there are few places that you need to edit. Please find them below. I have already to report a jira to improve them to configure from one config file.
repository/conf/carbon.xml
repository/conf/security/sso-idp-config.xml
repository/deployment/server/jaggeryapps/dashboard/apis/gadget.json
repository/deployment/server/jaggeryapps/portal/gadgets/account-recovery/gadget.xml
repository/deployment/server/jaggeryapps/portal/gadgets/identity_management/gadget.xml
repository/deployment/server/jaggeryapps/portal/gadgets/pwd_change/gadget.xml
repository/deployment/server/jaggeryapps/portal/gadgets/user_auth_apps/gadget.xml
repository/deployment/server/jaggeryapps/portal/gadgets/user_profile/gadget.xml
modify the url of the user_profile (i.e. http://{IP}:{port}/portal/gadgets/user_profile/gadget.xml ) in "repository/deployment/server/jaggeryapps/dashboard/apis/gadget.json" file in to HTTP and Port in to 9763.
I've spent over 8 hours trying to get this Django site up and running on an Azure Website. I've nearly thrown in the towel would really appreciate some help.
So far I have tried numerous methods and followed different tutorials, but they have all yielded the same result. Here is the most recent tutorial I have followed: http://www.windowsazure.com/en-us/develop/python/tutorials/web-sites-with-django/
Now that my site is "up", I am seeing a 500 error for all requests. Here is the error in the log:
The page cannot be displayed because an internal server error has occurred.
Most likely causes:
IIS received the request; however, an internal error occurred during
the processing of the request. The root cause of this error depends on which mo
dule handles the request and what was happening in the worker process when this
error occurred. IIS was not able to access the web.config file for t
he Web site or application. This can occur if the NTFS permissions are set incor
rectly. IIS was not able to process configuration for the Web site o
r application. The authenticated user does not have permission to u
se this DLL. The request is mapped to a managed handler but the .
NET Extensibility Feature is not installed.
Things you can try:
Ensure that the NTFS permissions for the web.config file are correct
and allow access to the Web server's machine account. Check the ev
ent logs to see if any additional information was logged. Verify the p
ermissions for the DLL. Install the .NET Extensibility feature if th
e request is mapped to a managed handler. Create a tracing rule to tra
ck failed requests for this HTTP status code. For more information about creatin
g a tracing rule for failed requests, click here.
Please help!
I got it working by settings up a new django project from the azure gallery and changed some configs and such.
Edit: The configs I updated was just the name of my app. In my case I also updated the database config with the database I wanted to use in settings.py.
The lesson learned from this is that it is easier to initialize the app from Azure's "Create from gallery" feature, and then pull down the source and modify it via ftp or git to achieve the desired project structure/naming.
For a number of sites that are functioning normally, when I run them through the OpenGraph debugger at developers facebook com/tools/debug, Facebook reports that the server returned a 502 or 503 response code.
These sites are clearly working fine on servers that are not under heavy load. URLs I've tried include but are not limited to:
http://ac.mediatemple.net
http://freespeechforpeople.org
These are in fact all sites hosted by MediaTemple. After talking to people at MediaTemple, though, they've insisted that it must be a bug in the API and is not an issue on their end. Anyone else getting unexpected 500/502/503 HTTP response codes from the Facebook Debug tool, with sites hosted by MediaTemple or anyone else? Is there a fix?
Note that I've reviewed the Apache logs on one of these and could find no evidence of Apache receiving the request from Facebook, or of a 502 response etc.
Got this response of them:
At this time, it would appear that (mt) Media Temple servers are returning 200 response codes to all requests from Facebook, including the debugger. This can be confirmed by searching your access logs for hits from the debugger. For additional information regarding viewing access logs, please review the following KnowledgeBase article:
Where are the access_log and error_log files for my server?
http://kb.mediatemple.net/questions/732/Where+are+the+access_log+and+error_log+files+for+my+server%3F#gs
You can check your access logs for hits from Facebook by using the following command:
cat <name of access log> | grep 'facebook'
This will return all hits from Facebook. In general, the debugger will specify the user-agent 'facebookplatform/1.0 (+http://developers.facebook.com),' while general hits from Facebook will specify 'facebookexternalhit/1.0 (+http://www.facebook.com/externalhit_uatext.php).'
Using this information, you can perform even further testing by using 'curl' to emulate a request from Facebook, like so:
curl -Iv -A "facebookplatform/1.0 (+http://developers.facebook.com)" http://domain.com
This should return a 200 or 206 response code.
In summary, all indications are that our servers are returning 200 response codes, so it would seem that the issue is with the way that the debugger is interpreting this response code. Bug reports have been filed with Facebook, and we are still working to obtain more information regarding this issue. We will be sure to update you as more information becomes available.
So good news, is that they are busy with it solving it. Bad news, it's out of our control.
There's a forum post here of the matter:
https://forum.mediatemple.net/topic/6759-facebook-503-502-same-html-different-servers-different-results/
With more than 800 views, and recent activity, it states that they are working hard on it.
I noticed that https MT sites don't even give a return code:
Error parsing input URL, no data was scraped.
RESOLUTION
MT admitted it was their fault and fixed it:
During our investigation of the Facebook debugger issue, we have found that multiple IPs used by this tool were being filtered by our firewall due to malformed requests. We have whitelisted the range of IP addresses used by the Facebook debugger tool at this time, as listed on their website, which should prevent this from occurring again.
We believe our auto-banning system has been blocking several Facebook IP addresses. This was not immediately clear upon our initial investigation and we apologize this was not caught earlier.
The reason API requests may intermittently fail is because only a handful of the many Facebook IP addresses were blocked. The API is load-balanced across several IP ranges. When our system picks up abusive patterns, like HTTP requests resulting in 404 responses or invalid PUT requests, a global firewall rule is added to mitigate the behavior. More often than not, this system works wonderfully and protects our customers from constant threats.
So, that being said, we've been in the process of whitelisting the Facebook API ranges today and confirming our system is no longer blocking these requests. We'd still like those affected to confirm if the issue persists. If for any reason you're still having problems, please open up or respond to your existing support request