I am working on setting up remote receipt validation for IAP and I need to generate an App-Specific Shared Secret. My account has admin privileges, however, when I click to generate the secret I get the error There was a problem retrieving the data for this page. Please try again.
This error is pretty useless and does not tell me how to fix the issue. I have reached out to Apple Developer support but have not gotten a response back. If anyone has had similar issues any help would be great!
Related
I have an app that uses the Twitter API where users can authenticate via twitter and retweet/like/follow through my app. Randomly this week the logs are showing "code: 89 Invalid or expired token".
Naturally, I go login to twitter to see the status of my app, and nothing seems out of the ordinary. I saw others with this issue had success regenerating their keys and replacing them in their application.
This didn't help.
One important thing to note is nothing has changed in the code of my application for the last 3-4 months, so I doubt it's anything in there. It's been working for over two years without any issue.
The thing I suspect the most is perhaps Twitter decided to suspend my app; Although, I don't see anywhere that is the case, and I thought I'd receive an email from them about it if it were.
I'm at a loss and would appreciate some possible solutions or alternative avenues I can pursue to find the culprit.
The keys associated with your app are the API Key (Consumer Token) and API secret key (Consumer Secret). The error you're getting is for the Access token, which belongs to the user. It sounds like the user associated with that request needs to authorize your app again before it can operate again with their access key. This can happen if the user removes authorization for your app by visiting their Settings/Privacy and safety/Apps and sessions.
If you were using your own access token in a scenario like single-user authorization, then regenerating the key might work, but in this case, the only way to get new keys for that user is for them to go through the sign-in process to authorize your app again. e.g. you could log who the user was that the error occurred on and send them a notification to re-authorize.
my mailer can't work because of this error. I can't understannd why. I use G-suite for my email.
Thanks very much for your help !
I had the same problem, recently Google really blocked the access to less secure apps.
But, you could resolve it turning on the 2 steps verification log in, and then the option app password should be allowed. this feature was created to applications that cant' make the 2 steps verification. Google will register a diferent password to be only accessed from this app.
https://www.google.com/settings/security
https://support.google.com/accounts/answer/185833?hl=pt-BR
Reason: Google was blocking access from unknown location (app in production)
Solution: go to following link and turn on https://www.google.com/settings/security/lesssecureapps
I am trying to run the sample Google Apps Script Service Account OAuth example taken from here:
https://github.com/googlesamples/apps-script-oauth2/blob/master/samples/GoogleServiceAccount.gs and keep getting a server timed-out error. I copied the exact code and just substituted in the private key, client email, and a user email. The example code looks to be current as there was an update to it on July 30th.
I have authorized https://www.googleapis.com/drive/v2/files through the admin console as well as https://accounts.google.com/o/oauth2/token and have listed these as scopes in the admin settings (and domain-wide delegation is enabled). I am using an admin account to run the script.
I keep getting the ubiquitious "Server Timed Out" error and nothing shows up in the Execution Logs.
What might be the problem? Any help would be appreciated. Thanks in advance.
Thanks, Gerardo, for pointing me in the right direction. It turned out that our organization manages permissions for the Google Developer's Console by Organizations (in the Google Admin console). Somehow a few accounts, including mine, were kicked out of the Organization that had permissions to access the Developer's Console. After adding myself back in, the sample worked without problems.
I am using Paypal REST api to create subscription plan and subscription agreement. I am able to create subscription plan and credit card but not able to create agreement. Whenever I request it gives internal server error.
I am using ruby gem paypal-sdk-rest
Credit card I am using is
4012888888881881
And mode is Sandbox
the Response I am getting is
Response code = 500. Response message = Internal Server Error.
Response debug ID = ea61a34e9fa73
Thanks in Advance
It happens because of frequently used test Credit Card like the one you are using, if you are use different one for this it will help you to solve this issue...
Or may be below one cause of the error
Sandbox Personal Account being used was invalid. The sandbox personal account is causing all this error 500.
HTTP 500 is caused by an internal error. One of the possible root causes is what JIGNESH mentioned.
Can you please open a Github issue with the information you provided here? It is a better place to discuss this kind of issue.
Also, would you explain how you are using subscription? Ruby REST SDK does not yet support the feature, although it is coming soon. Did you add it yourself?
I have a custom mdm solution running for IOS.
during enrollment, I am using HTTP basic authentication to pass the user name and password to be verified against our db/AD.
if the user is denied access, I send a 401.
however, on the IOS side, it pops up an error that says "safari could not install a profile due to an unknown error". Seems like a pretty bad error where I want it to say access denied.
Also there's an issue that safari decides to cache the credential used, so I don't get a chance to re-enter the user/pass again unless I clear all the cookie/cache data.
Anyone have met this issue before?
Looks to be issue with my code.
I've sent a 401, but actually the specification calls for a WWW-Authenticate header to be sent as well. With that added it, it's working normally now.
Have you considered using a more widely tested MDM solution such as AirWatch? A solution such as this has integration with AD and would be an excellent option for you to evaluate.