I can't login to iTunes.connect anymore. It delivers an empty white page since the whole day now. There is no 401 and no 404, just plain html that renders an empty page:
https://www.youtube.com/watch?v=UhIy6OeaBZY&feature=youtu.be
My friends can log into itunes connect and see the real page, but not me.
I tried different browsers, cleared cache and everything else.
What to do now? Apple isn't interested in this issue because it works for lot of people apparently....
I don't think there is anything you can do about it on your end, but I wouldn't panic. I believe it may be traffic and/or account related. We have it happen every now and then and usually after a couple of hours things are back to normal. Should the issue persist, I absolutely would contact Apple regarding it though.
As #Ramsay also commented, some more people had this issue yesterday...
How i ended up with this: i switched the network to 3G UMTS where everything worked fine.
Then I disconnected the router for a while to achieve an IP-address-change from my provider for my office. But iTunes.Connect then worked only in incognito mode, so i had to clear browser cache with cookies again. Now it works.
Apparently iTunes.Connect had some serious issues in general. The processing-state for a new release in the internal-testing-phase of Testflight took more than 5 hours yesterday. Usually 10 minutes where enough to process.
Related
I'm trying to help a client with their slow-ish website https://www.dp-tools.de. If I use Google page speed for mobile I can see that it takes 7 seconds to be interactive but nothing in the found problems really tells me why it is actually that slow. I also tried chrome lighthouse and couldn't really see all that much.
Is there another way of checking or maybe anyone here sees why it is so slow?
Open up the client's Shopify Admin, and examine the theme. Does it have any strange slow code in it? Examine the Apps installed that directly affect theme. Are any of them crap, old, broken junk?
The best way to debug a slow theme is to just start hacking out any junk the client may have added to their theme. A lot of themes are so bad, for example, they load jQuery 3 times. Likely you have one bad apple in there, a call that is blocking and takes way to long to timeout or respond. Developer tools can point these out to in your console. Mobile versions have to come with a developer console you can inspect too right?
I found a lot of posts about this issue, but none is like mine.
I have a website that subscribes to IG real-time updates. Since some time ago trying to subscribe to new notifications returns the above error. Seems like IG can't reach the callback_url.
Interesting findings while troubleshooting:
I tried to manually (directly) access the callback_url and it works flawlessly.
When I run the site on my local machine and make sure the callback_url is to my server + the verify_token is a valid one then it all works as it should! IG reaches the callback_url.
I used the apigee console to make the subscription request and there it sometimes works.. Meaning - I craft the request to IG API and click Send. If it fails then I click again (I don't change parameters) and then it works..
Web server logs are in line with the results I get (when it complains it can't reach then there's no log of a request).
Does anyone have any tip or suggestion how to fix this?
Thanks!
While chasing my own tail for a solution I also contacted IG support. I described the issue using same description as above.
After 2 weeks suddenly everything started working again. Magic! Suddenly no errors at all! Needless to say nothing has changed on my end (hardware / network / code).
I didn't receive any response from their support, but considering that a previous email to them a few months ago took about 2 weeks to answer then I am quite sure some support guy simply fixed the issue on their side and didn't even bother to let me know what was going on.
This could be related to the fact that they killed most of their real time notifications API.
Anyway, leaving this here so that if anyone encounters a similar issue then just know you may need to email IG support.
Many of our users are reporting that they are getting a blank page when using IE11 to access our website. Sometimes they don't even get a blank page, the browser just stays on the last page visited. These users can access other domains (such as google.com) without a problem.
For the browsers that are failing, if those users disable Protected Mode in IE, then they can again access our site, but this isn't a good solution because we have thousands of users and we can't go telling each of them to reconfigure their browsers, not to mention that we're completely losing the business of those potential customers who just surf by, see a blank page, and then keep on going without filing an error report.
Firefox and Chrome work fine. Also, even when using IE11 in protected mode, some users have zero problem, their computers just seem to work.
We are running the site off of IIS7. Other sites on the same server run fine, it's just the one particular site that is having the problem, and it's intermittent, affecting some computers and not others.
There must be something I can do on my side in the server or network settings to keep this problem from happening, but I'm baffled as to what it might be. When I look at the network traffic on a browser that's failing, the GET request is just being aborted with no explanation. When looking at the traffic with Wireshark, I see no errors, and no errors are showing up in the IIS logs. Of the browsers that fail, they are not even opening a connection to our web server to make a GET request, the request is just aborting immediately.
Any advice appreciated!
(followup): Another test we did: We can reproduce the problem on our development server, with the same pattern of which computers "work" and which don't. We tried turning off the webserver, and the problem stayed consistent, we'd still get a blank page error. So it's obviously not to do with anything that's in our page content? I've run tests on 9 computers on our office network: 5 worked, 4 failed. We're all baffled. :/
(January 24 followup): We figured out what's causing the problem, but not how to fix yet. Deep in the Windows registry, a key is being set in a Zonemap folder, adding a "play.net" domain with a key value of 2. IE sees that key when someone types play.net, and quivers and dies without an error message (Firefox and Chrome handle it fine).
So next question, what is setting that key in the first place? Probably an ActiveX control somewhere, but we haven't had any luck finding it in this 15 year old site, as many of the coders who may have created ActiveX controls in the past are long gone.
Does anyone know of a way to scan an entire domain and list anything that might be twiddling a registry key?
Followup mail threads from Elonka indicated that some users had the play.net domain mapped to a specific / non-default Internet Explorer security zone, and those users were the ones having problems.
Try add
<meta http-equiv="X-UA-Compatible" content="IE=10" />
into the header. It fixed IE11 for my website. It just forces it into IE10 mode (A complete joke though)
I accessed your domain in Internet Explorer 11, with Protected Mode enabled. I was unable to get a fully broken experience, but I did see something perhaps related to what your customers are experiencing. Some directories on your domain would hang for me, resulting in a white screen if they've not yet been loaded, or staying on the present page while the forthcoming page is loaded.
When I navigated to /dr, I found that my browser hung for over 7 seconds while your files loaded. Note, there were roughly 60 items, totaling about .78mb. This isn't much, but I'm presently on a relatively slow connection, and this resulted in a hang for me.
I would inquire what connection speeds your clients are on when experiencing this issue - it could very well be nothing more than some directories being served up more slowly than others. Regardless, you could optimize the experience considerably by compressing and concatenating your CSS files, as well as all of your JavaScript files. This results in fewer parallel requests, and quicker downloads.
If you have a reproducible example, please feel free to share and I'm sure myself and many others here will be more than happy to assist you.
For me box-shadow on an element caused this behavior. I removed the box-shadow(but left -webkit-box-shadow and -moz-box-shadow) and the problem disappeared. The interesting thing is that I still have box-shadow on another element...
If you are using 'offline.js' in your project, and you have version less than 0.7.19, then IE11 latest security update will see this code as potential security threat and block pages which are using 'offline.js' code.
Solution: Update to latest 'offline.js' version.
we are developing an extension, hosted in the Google chrome web store.recently - we've got complaints from our users that sometime they get a notification window saying "the extension crashed, click here to reload".
after a short research we found out that this is happening only when we upload a new version to the Chrome Web Store.
we started to look it up online and found no documentation what so ever for this, so we started to check for it ourselves.
we tried to see what exactly can cause this problem and if we can identify a distinctive cause.
our tries included updating only the manifest.json file, a css file, a js file or not changing nothing at all but the version number, and on each change we've uploaded a new version and update it in about 10 different machines.
the results were the same, when on each update we made, it caused the extension to crash on just a few of the machines, while updating perfectly fine on the others. each time different machines acted differently.
then, we thought it might be related to the fact we have a timer working in the background page, and it might be happening just at the time it is working.
so we tried to raise the timer's frequency (from 5 seconds to 100 millisecond), and it still acted the same, crashing on only 3 out of the 10 machines.
we ran out of ideas now, and it really causing a problem in terms of user experience to our extension's users.
did someone had this problem, or came across any extension crashes on version update?
is it a known bug in chrome's extension engine or are we doing something wrong?
I am having the same problem and I think I found the cause. Do you by chance, override the new tab page?
I am able to reproduce the problem 100% of the time and when I remove the new tab override from the manifest, the problem goes away.
I opened an issue: Issue 104401
Is there a trick to logging in to Apple Developer Connection? For the past two weeks, out of about 100 tries, I've been able to log in three times. Every other time, after a successful entry of my username and password, it takes me back to the login screen.
This happens to me on both my Macs, on Safari and Firefox, so I'm not hopeful of a solution. But I have a hard time believing that the situation is really this bad...
I am having the same problem, I have narrowed down to a problem with my ISP. Of course they will not acknowledge it, but the problem only arises when I attempt a login from home. I think they are probably using a caching proxy and something in the scheme used by apple to login->access the content makes the proxy believe it's only visiting content that is still valid. I am going slightly mad because of this.
This question and the related discussion clued me in to how to fix my problem with the same symptoms on developer.apple.com. In my case, I have multiple "teams," so after entering in my Apple ID, it takes me to a team selection page. After selecting a team, I'd just be redirected back to the login/Apple ID page.
Turns out, the login is done over HTTPS, while the team selection (and probably the bulk of other activities on developer.apple.com) are over HTTP. Our firewall load balances over a couple of Internet connections, and the HTTPS traffic was passing over a different interface than the HTTP. Evidently, this was confusing Apple's authentication mechanism. It also explains why I was occasionally able to get through -- sometimes all traffic would end up on the same interface.
Ultimately, my solution was to add a rule to the firewall to send all 17.0.0.0/8 traffic (Apple's legacy class A network) over the same interface.
Hopefully this helps someone else with a frustratingly endless login loop.