Since yesterday we're getting error 403 after the point of entering bank details in the fastlink using DAG banks. It works ok for Live accounts but not Dag.
This has been working previously and stopped working around 1.30pm (UK) yesterday.
We also contacted Yodlee by email and was advised they would look into this problem asap. The problem is now resolved.
Related
Very frequently official YouTube website errors out. It works in incognito mode if I try. Which tells me the issue is due to one of cookies / cache / localstorage / application-data on the browser.
If I delete the data, it will start working again, but, I will need to sign-in again in all the gmail-accounts that I use.
I've asked Google (in feedback and over twitter) to look into this but they can't help it.
So, questions:
If anyone has faced this issue, have you figured out why and how to fix it without signing out from accounts?
How do I go about debugging this?
I've taken a memory heap snapshot on chrome but have no idea how to analyze it.
Is sending a memory heap snapshot as part of feedback or to anyone else secure?
So, I figured out the solution. Tried looking at patterns in general in the memory of the browser (localstorage, etc) and found the following in cookies and here's what fixed it (without signing me out of my accounts).
In the image below - there are lines which have gsScrollPos-xyz with a past expiry date. I deleted all of those. I understand that only Google will be able to figure out why that caused the issue and I will send them the feedback.
I have three laptops and one desktop joined to Active Directory hosted on Azure. I am trying to join a new workstation to Azure AD using the email address of a person who has a laptop connected to Azure.
Here are my steps.
Connect to Work or School.
Connect.
Join this device to Azure Active Directory.
Enter user's email address and password.
I receive the following error when trying:
"Looks like the MDM Terms of Use endpoint is not correctly configured."
I've checked whether "Users may join devices to Azure AD" is set to ALL. (It is.)
The number of devices per user is set to 20.
Where do I go the portal to resolve the issue?
I know that this is an old question but I'm hoping it can help others avoid hours or days trying to figure out. Even Microsoft couldn't figure this one out which is sad. Their documentation actually even contradicts the solution.
During your domain setup, there are two CNAME records that you are instructed to create: EnterpriseEnrollment and EnterpriseRegistration. What they don't tell you is that this is only used if you are using the free MDM for Office 365 solution. If you are using, or switch to a license of Active Directory Premium and/or Intune, you MUST remove these CNAME records in order to allow your devices to register. It worked for me instantly upon removing the records on Cloudflare, though there may be a delay depending on who you use for DNS management.
I hope this helps anyone encountering this issue. Microsoft really needs to work on the detail of their error messages.
I see you got a couple answers on Reddit - but here goes,
Firstly, make sure you have one of the more advanced AAD services (such as P2) not the free one which has almost nothing whatsoever to do with AD.
AAD seems to "propagate" slowly ala Y2K Domains. I get this error often and there might be more than 1 root cause (thanks to the cryptic message in the first place).
Similar symptoms:
MDM TOU error when activating brand-new PC
Vague error regarding connectivity when setting PIN
"Successfully" connecting to work but no listing in Intune
For all of the above, I find simply waiting about 24 hours before trying again often helps as the newly created user/device/passport/hello propagates through Microsofts complex cloud ID servers.
I have had it fail with your message and then retry 30-seconds later and it works (forever from then-on) and I have had devices which "join the workplace successfully" but not show up in Intune/AAD for almost 48 hours!
I have experienced significant variability when using the Instagram Subscription API. For the most part, the API will not post updates to my end-point as specified during the subscribe initiation. My understanding is that the subscription is configured correctly as any of the updates from my personal account are received.
There seem to be reports across the web talking about significant delays. However, it is my experience that accounts that work do so within seconds but in most instances no subscription messages are never received.
There was discussion on the web also regarding queuing of updates sent through to the subscribe API. Which may make a little sense, however a queue would suggest that updates would be received eventually.
I have requested basic permissions, which is sufficient to request public media from each registered account. Yet, there I have a gut feeling that these permissions could be the problem, so I have started the process of requesting public_content.
At this stage there seems to be a number of developers experiencing similar issues, yet no resolutions.
Has anybody been able to resolve this issue?
I'm subscribed to aspect=media object=user and experiencing a similar issue.
For some users, I'm notified 95% of the time. For other users, I've never been notified of a single post.
In this post nithinisreddy mentions that the data is being "sampled". I think this is the reason. Hopefully it improves after the tags/locations subscriptions are deprecated.
I am developing a website and it accepts payments for membership, paid using Google Wallet.
The DEV environment works. The call back function is intercepted, authorised, and the membership is automatically extended as expected.
The remotely hosted environment which should go live soon doesn't want to know.
When the user clicks on buy, an error message immediately pops up. It is ok for the user, but it doesn't say much else, making it useless for the developer. Maybe it's just me not finding the error code, or something similarly useful?
Anyway, the originated JWT String is valid ( the decoder here http://openidtest.uninett.no/jwt decodes it correctly, and the data in it is right ).
Any suggestions on how to fix?
I don't know if this is necessary at this stage or not, and possibly the cause, but the bank account hasn't been verified yet. ( For the developing I used the standard provided US sandbox account, I really hope that Google Wallet accepts UK bank accounts too, can anybody out there confirm? )
I found the cause of the problem, as mentioned above. I wasn't able to pick my own post as an answer before now. Best is to follow the steps above in case you do have problems caused by a missing one, different from mine. A big thank you to EdSF for his help! :)
I've looked at the various questions on this topic but none of them QUITE fit the problem I'm having.
I've developed an MVC4 app which utilizes DNOA to call into a particular provider (Intuit). All worked perfectly on my local IIS (testing) but when I deployed to Windows Azure I get the proverbial wonderful "strange, intermittent" behavior. Specifically, 99% of the time, the initial sign-in request results in the "No OpenID Endpoint Found" error; however, SUBSEQUENT sign-ins go through without a hitch.
I've added the code referred to here: ServiceManagerCode, to no avail. I've checked and the OpenID URL is correct. I've also attempted to add log4net to see what might be occurring but have been unable to do this correctly, some other answers seem to suggest this returns nothing anyway. I've also asked Intuit but, so far, no responses.
Again, if this wasn't occurring on just the first attempt then there would be numerous relevant posts but with this peculiar behavior I am wary of wasting inordinate amounts of time on a wild goose chase.
Any suggestions, however slight, would be very much appreciated.
I am not familiar with OpenID. Is the OpenID sign in service hosted by you in Windows Azure as well? Please make sure the sign in service has started without any problems, one suggestion is to check the federation configuration. Most federation providers require you to configure the realm and return URL. If they’re not properly configured, the application won’t work.
Best Regards,
Ming Xu.
Since you say that your Azure relying party works reliably after the first failed attempt, perhaps you can workaround it by having your app_start event in your Azure web role call DotNetOpenAuth's OpenIdRelyingParty.CreateRequest method, not doing anything with its result, just to 'prime the pump'?