In a few days' time my SSL certificate expires on PayPal. Normally I would go to Account Settings > Website Payments > Encrypted Payment Settings to upload a new certificate. However, attempting to do so since several days yields a "That page doesn't exist" error. From reading other forums it would seem I am not alone. PayPal Cust Support know nothing of this, and I am still waiting on a response from PayPal Merchant Tech Support (MTS). However, time is critical and in a few days' time I will be completely dead in the water if I cannot upload a new cert. I've heard an unconfirmed rumour that Encrypted Payment Settings is no longer supported, although I've had no official comms. Can anyone confirm?
Needless to say if this is something PP are quietly retiring under the hood with no warning, thereby knowingly and suddenly leaving people without a working eCommerce solution then...
Related
I want to use the gmail api to update myself about the status of a programm I'm running locally 24/7. Basicly once a day it should send me a status report per email from the emailaccount I created just for this case to the same account.
I've got a project set up, the api enabled, got my credentials and created a token.json file. I managed to have it send me emails yada yada yada.
I concentrated on the further development of the programm for some time and then wanted to jump back to this to test out another feature where I wanted to implement a ping me feature. I'd send myself an email asking for a ping back just to check if my program is still running.
While doing that I noticed that my token expired. I tried reading into what I can do about that. Ideally I'd like to have the program just run autonomously. I read for my case that a service account would be ideal but after setting that all up and 2 hours later after a lot of errors I read that interacting with the gmail api with a service account is only open to workspace users since I can't delegate domain-wide authority without one.
So after some further reading I read that next to the access token I created I can refresh that token with refresh tokens. for that I was trying the request function noted in the quickstart tutorial:
if os.path.exists('token.json'):
creds = Credentials.from_authorized_user_file('token.json', SCOPES)
if not creds or not creds.valid:
if creds and creds.expired and creds.refresh_token:
creds.refresh(Request())
now running creds.refresh(Request())
I get this error:
google.auth.exceptions.RefreshError: ('invalid_grant: Token has been expired or revoked.', {'error': 'invalid_grant', 'error_description': 'Token has been expired or revoked.'})
Upon further reading here I read that refesh tokens are only available to projects whose status is set to in progress and not in testing. Projects set to testing are required to have the user manually log in at least once a week which I don't want.
Now for me verifying my project doesn't make sense since I won't have any other users using my access to the gmail api and frankly I wouldn't want that either.
What are my options here to have the script running continuously without having to manually sign in once a week? Considering also that I will be at all times the only user.
Thank you,
Florens
Your still have a few options. For one, you could get a Google Workspace account. The lowest tier would set you back around $6 per user per month. This would allow you to publish the app as internal-only and you don't need to go through the verification process, but you can only use the app with the Workspace account. You can still send emails out to any addresses, though.
If you don't want to pay, you can still set your app to Published status and you do not necessarily have to go through the verification. There are some limitations, such as the app warning that shows up when signing in and a user cap of 100 users, but since you know that the app is safe and you don't need more users you can just ignore this, Google says so in their own documentation:
What app types are not applicable for verification?
Personal Use: The app is not shared with anyone else or will be used by fewer than 100 users. Hence, you can continue using the app by bypassing the unverified app warning during sign-in.
As you already know, the refresh token expires in 7 days only when the app status is set to "testing", so as long as you have it set as "In production" and ignore the unverified app warnings, you should be able to have a normal refresh token that you can use without needing to sign in every 7 days.
Just keep in mind that other users could have access to the app but if you're careful to keep your OAuth credentials to yourself that should not be an issue.
Sources:
Unverified apps
OAuth API verification FAQs
OAuth overview
URL: https://pilot-payflowpro.paypal.com
Until 12 April 2017 I had no problem but as of 13 April I failed to create a secure token.
There were no changes to the code nor to the account settings (no change in password, no "allowed IP addresses, ...").
The same code using paypal production accounts still works.
Apart from the TLS 1.2 and HTTP/1.1 upgrade I don't know about any changes on the PayPal server side.
Anyone having similar problems?
After some more digging I decided to contact PayPal technical support and I eventually (after 5 weeks) got this reply:
"There was a batch a few months ago that disabled Test accounts that hadn't been in use for a while.
They can be re-enabled only from our side...
Apologies for the inconveniences."
They kindly re-enabled our accounts and all was fine again.
i have a scenario running with an own CALDAV-server and CALDAV-clients like (iOS-calendar, mac-Calendar, Android sync adapter, Thunderbird/Lightning, Outlook Sync, ...)
The authentication so far works via basic auth (https and the "Authentication"-Header).
The CALDAV-clients store the user/password in their configuration.
So far so good, but the issue comes now once the password of the user/account either gets changed, reset, expired, etc.
The server has a restrictive password policy enforced, which locks the account after x failed attempts (e.g. 10).
What is happening now obviously is, that once the CALDAV-client configuration was not updated it continues to use an old password.
The server responds with an 401 not authorized - ok, thats fine apparently again.
But the Clients still continue to use the outdated password. It would be nicer to stop polling and present the user with a dialog that his credentials are not valid anymore. But the clients are out of my control so nothing can be directly done here.
The result: after 2-3 iterations (as most clients tries multiple request in one sync iteration) the account on the server of the user is locked due to too many failed login attempts.
That is not nice. The issue seems to be generic and known as "stale passwords".
A solution could only be a better client handling (out of scope here) or a oAuth-token handling. But i was not able to find anything that standard CALDAV-clients supports this. Only google calendar seems to enforce an oAuth2 authorization before allowing CALDAV communication.
So the question is, is there a good way to improve the bad experience of locked accounts?
Some special 401 response which tells the clients to forget the password or not using it again?
constructive feedback highly welcome.
Edit:
for macOS and ios calendar i found a strange behavior (bug) causing and/or enforcing the described situation.
A standard 401 response will cause the clients to bring up the password dialog as expected and described above. The clients stop polling until a new password is entered - as desired.
In my case the 401 response body contained an inline base 64 image (img src="data..."):
This doesnt lead to a password renewal dialog! Just a "something goes wrong" error state.
The clients are continuing to poll! Locking the accounts after some tries ;(
A solution for this problem than will be to remove the inline image but for me it sounds like a bug that an inline image in the 401 response provokes a different behavior on the client.
Some special 401 response which tells the clients to forget the password or not using it again?
Well, 401 is that response. If the client receives a 401 it knows the the login/password combination it provided doesn't work anymore, and shouldn't retry with the same. Obviously the clients don't do this, partially because:
On the other side your servers x-failed-attempts locking doesn't work with stateless protocols for obvious reasons. HTTP doesn't have that feature builtin. Locking the account is a side effect a client doesn't have to expect when running idempotent HTTP requests.
Assume the client is downloading 10 batches of items concurrently. If the credentials invalidate during this, the account would immediately be locked :-)
Summary: You can't use basic auth naively with backends that lock accounts after n-tries.
Google and iCloud both use token based auth schemes (Google OAuth, iCloud a proprietary one). You can't expect those to work in other clients. E.g. while the Apple clients support OAuth for Google, I don't think they support that for other account types.
So what can you do
I'm reading your question so that you own the account server and that the account locking is intentional and desired. (I.e. it is not a side effect of a different (e.g. SSO) backend system you reach out to.)
I think in this case it should be reasonable to rework your account system to allow unlimited login attempts with just the old password.
The lock-after-n-attempts measure is to protect against people trying different passwords. In your case it is always the same and as a bonus it also matches the old password.
There are a lot of different variations of this approach.
So for a while I've been relying on the PLAIN support for logging into Google's IMAP server in my email client. Recently they started blocking that and return an error (despite listing it as a supported authentication method).
For instance take this example:
Connected to 'imap.gmail.com:993' using SSL
A0001 CAPABILITY
* OK Gimap ready for requests from ##.##.##.## cd6mb38777249ieb
* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN AUTH=XOAUTH
A0001 OK Thats all she wrote! cd6mb38777249ieb
A0002 AUTHENTICATE PLAIN
+
####################################
* NO [WEBALERT https://accounts.google.com/ContinueSignIn?sarp=1&scc=1&plt=AKgnsbszktZSU6iVmh...snip....] Web login required.
A0002 NO [ALERT] Please log in via your web browser: http://support.google.com/mail/accounts/bin/answer.py?answer=78754 (Failure)
SSL connection closed.
ScribeImap_Thread.cpp:647 - Connect to imap.gmail.com:993 failed.
I've tried opening the "https://accounts.google.com/ContinueSignIn..." URL in my browser:
And I get redirected to https://myaccount.google.com/ but the next login attempt fails as well. So it doesn't seem to change the authentication at all.
Is the PLAIN authentication just blocked completely or am I doing it wrong?
Alternatively is there a authentication method that works and DOESN'T need a browser component to log in? (XOAUTH2 seems to need a web login as well)
It's pretty official:
http://googledevelopers.blogspot.com.au/2015/04/a-final-farewell-to-clientlogin-oauth.html
They have shut off PLAIN login completely and it's not coming back.
So there are two options:
Turn on "less secure apps".
Implement OAUTH2.
I've decided to implement OAUTH2 support (which isn't too far off working actually). Initially I thought I would need an embedded browser component in my app, but it turns out that I can launch the system browser and the user can copy the token across in a some what manual process.
Interestingly for those working on OAUTH2 support in their software, Google have setup a playground to see the whole process in practice:
https://developers.google.com/oauthplayground/
I see that this is an old post, but after fighting with Outlook for over a year to get my mail, I FINALLY got it working again.
The first thing I had to do was log into my my Gmail account and turn off the button labeled "Less secure apps" as Outlook is in that category.
Go to the "Less secure apps" section in My Account.
Next to "Access for less secure apps," selectTurn on. (Note to Google Apps users: This setting is hidden if your administrator has locked less secure app account access.)
And if you have 2-step verification on (as I did), it will still make Outlook fail. So the next thing you have to do is create an app password which will generate a password for you, and you use that in Outlook for it to sync correctly.
Visit your App password page. You may be asked to sign in to your Google Account.
At the bottom, click Select app and choose the app you’re using.
Click Select device and choose the device you’re using.
Since Outlook will not be listed, select Other and type in Outlook for future reference.
Select Generate.
Follow the instructions to enter the App password (the 16 character code in the yellow bar) on your device.
Select Done.
Copy the password that was generated.
Open Outlook and paste the password in the Password section. DO NOT use your regular password.
Your mail will sync without anymore issues. (Hopefully)
Once you are finished, you won’t see that App password code again. However, you will see a list of apps and devices you’ve created App passwords for.
I hope this helps everyone who is having an issue. And I hope these directions are easy to follow! Good luck everyone! :-)
mod_authn_otp is an Apache web server module for two-factor authentication using one-time passwords (OTP) generated via the HOTP/OATH algorithm defined in RFC 4226. The developer's has listed only one compatible device (the Authenex's A-Key 3600) on their website. If a device is fully compliant with the standard, and it allows you to recover the token ID, it should work. However, without testing, it's hard to tell whether a device is fully compliant.
Have you ever tried other devices (software or hardware) with mod_authn_otp (or other open source server-side OTP program)? If yes, please share your experience :)
Any device that claims to be "OATH Compliant" should -- and probably does -- work.
The hard part is not compliance, it's getting the vendor to give you the secret key associated with the token. The don't like to do this because they make their money off the servers, not the tokens.
Note this new iPhone app also works if cell phones are an option for you.
If you're looking for more options, consider using mod-auth-radius or mod-ldap. Most two-factor auth solutions support radius and ldap and you will get far more options and flexibility. Plus, you can do things like run your radius auth through Active Directory and then have IAS/NPS proxy the request to the 2FA server. Thus, when a user is disabled in AD, they are disabled for 2FA too.
There are a couple of ways to do mod-radius:
https://www.wikidsystems.com/support/how-to/how-to-configure-apache-to-use-radius-for-two-factor-authentication-on-ubuntu// and https://www.wikidsystems.com/support/how-to/two-factor-authentication-for-apache-22-or-higher/