https://onesignal.com/provisionator always returns
"Incorrect 2 factor auth code! Please double check the code and try again." - when code is correct. Tried 3 times - always the same error.
Support suggests to manually generate certificates, though it's inconvenient. Did somebody was able to use provisionator recently?
If so - how do you login?
Please, vote for issue to bring support's attention, if you experience same problem with provisionator.
how do you login?
You log in in step 1 where it says enter your Apple credentials.
Perhaps double-check to ensure you're using the correct login.
Yes, alternatively you can always manually create the credentials.You can learn how to do that here: https://documentation.onesignal.com/docs/generate-an-ios-push-certificate#method-2-create-a-certificate-request-manually
Related
Hi Everyone this is my first question... its taken 4 years for me not to find the answer through others questions and google.
I am new to Oracle APEX 5 and administrating ORACLE APEX 5 for our DEV, System TEST and OQ environments and the DEV and ST environments have started producing this error when I try and click on a user to configure their passwords or changed their accounts to unlocked. I am using the ADMIN account which worked last month when I went in to reset a password for a developer. The error is below (I would rather have posted a screenshot but I am unable to as its my first question)
Internal Error Contact your administrator. Details about this incident are available via debug id "6818".
Can anyone tell me why this is happening and where to find the debug log or how to fix the problem?
Many thanks
Regards,
Helen.
This is an unhandled exception. We'd need to get the details of this exception to understand the problem better.
To find the details, you can either connect as SYS or SYSTEM (or someone granted the APEX_ADMINISTRATOR_ROLE database role) and run the following query:
select *
from apex_debug_messages
where page_view_id = 6818
order by message_timestamp asc;
By the way, this was so poorly documented, I decided to author a quick blog post about it. Thanks for the inspiration!
Joel
Thank-you for your reply
I got a few rows back from the query the one the sparked my interest is the following
ORA-01841: (full) year must be between -4713 and +9999, and not be 0
I updated the admin password in previous months to not expire as this is not needed.. The password still expires though even with this set to no. So I entered 99999 as a way to bypass this. I just change the days to within the range requested above and the page now displays. Very silly mistake on my side in the end! Thank-you for the info as it is a great help to know where these DE-BUG ID's are stored
I have searched the answers to similar questions asked about this SagePay error, and checked that the fixes don't appear to apply to my problem.
Specifically:
I am using a correct 2-letter country code for BillingCountry and DeliveryCountry.
I am POSTing VPSProtocol, TxType and Vendor as well as the Crypt value.
I have re-checked that I am using the correct encryption key from the MySagePay test portal.
Now I was using http://localhost:8084/app/success and http://localhost:8084/app/failure for my success and failure URLs, since I thought that although these are (obviously) not visible externally, it shouldn't matter since SagePay is re-directing at the end of its part of the transaction. (Is this assumption correct, or do these URLs need to be externally accessible?) Some of the answers have thrown doubt on this, so I changed them to an external website I own, and I still get the same error.
Another line of thought is that the client I am developing for has already gone live, and there seem to be hints that once you have gone live, you no longer have access to the test server (Is this true?)
Is there anything else I should be checking? (Additional info: I'm using the SagePay api (sagepay-api-1.2.2.0.jar and related libraries) to validate the form contents and encrypt them.
I used the integration from https://github.com/tolzhabayev/sagepayForm-php
I had this error (5080) and spoke to SagePay support and they guided me to the MySagePay portal where you can view Invalid transactions to be able to troubleshoot this error easily!
Hope this helps someone.
Chris Rickards
I had exact same problem and I tried everything that you described as well, one day after I found that the problem was in "VendorEMail" field, it had 2 email addresses separated by ;, once I removed second and left only one email everything worked.
Recently transferred my Magento 1.7 store to a new host, and started having a frustrating problem.
We've got the store sitting behind a login shell - you can see it at http://www.seacadetshipsstore.com. Base exchange takes you to the root store (/magento/), and the gearlocker login takes you to a secure sub-store (/magento/gearlocker/).
The problem is, ever since transferring to the new host, /magento/gearlocker/ is sporadically redirecting to /magento/. I can only reproduce it 1 in every 10 times, but customers are constantly complaining that they can't access the secure store for this reason.
I've also noticed that if I turn off the security and have clients navigate to /magento/gearlocker/ directly, it seems to fix the problem for most - they no longer get the redirect after logging in. Only a few of them still have the error, and they're all PC users on various browsers.
I've set up a demo login for stack:
https://www.seacadetshipsstore.com/login.php
U: stack_login
P: thanks
I doubt it's an issue with the base url or base link url, otherwise the error would be much more consistent. I've gone through magento's official tutorials and made sure the secondary store was set up properly (remember, it was working fine on the old host). I also know it's not anything to do with the login shell - all it does is validate the user's login and redirect to /magento/gearlocker/.
Can anyone reproduce this error? Can anyone tell me what's going on, or how I might fix it? Thanks in advance!
I am attempting to incorporate Windows Live ID in my application.
First, I created a Windows Live Dev Application account, here:
http://msdn.microsoft.com/en-us/windowslive
Let's pretend my Client ID is 12345 (of course, it's really quite longer)
Then, I followed these instructions:
http://msdn.microsoft.com/en-us/library/hh243647.aspx
This suggests the following sample URL:
https://oauth.live.com/authorize?client_id=CLIENT_ID&scope=SCOPES&response_type=token&redirect_uri=REDIRECT_URL
I use this custom URL:
https://oauth.live.com/authorize?client_id=12345&response_token=token&scope=wl.signin%2cwl.basic%2cwl.offline_access&redirect_url=https%3a%2f%2foauth.live.com&display=touch
Horray, the user get's prompted to login!
Boo, the user is redirected to an invalid page.
Is there something I am missing here? Thanks in advance.
The error was in my URL, of course. The correct would be:
https://oauth.live.com/authorize?client_id=12345&response_type=token&scope=wl.signin%2cwl.basic%2cwl.offline_access&redirect_uri=https%3a%2f%2foauth.live.com%2fdesktop&display=touch
Hope this helps someone else trying to figure this out!
I have my own openid provider on my website, with phpmyid. It worked flawlessly until now, but apparently now it's not working anymore. I am unable to login anywhere I tried. How can I debug what's going on, to understand where's the problem ?
I can add more details if required, but if I can figure it out by myself without having to paste stuff it would be better.
Without any details, all I can say is read the logs (if phpMyID provides any), and capture the browser redirects with something like TamperData to see if there's anything obviously wrong there.
You could also try http://test-id.org/