glpi error connecting to gmail - gmail

I have installed GLPI 0.90.1 on a CentOS 7.
After more and more problems, everything was going right, but I tried to configure an IMAP mailbox on it in order to create tickets from mail.
The first time I collected my mail (for test), it works well. The ticket is created.
But the second time I tried (maybe 20 minutes later),
I get an error :
"connexion bloked" (translated, because I'm french).
I thought it came from Gmail, but the configs were good, and I didn't change anything.
On Glpi, I do not understand my error messages in the .log.
So I come here to find answers.
If you need more informations, tell me.

Maybe you must enable allow less secure apps to access account on your Gmail account.
Related: What are the dangers of allowing “less secure apps” to access my Google account?
"less secure apps" refers to applications that send your credentials directly to Gmail

Related

How do services/platforms uniquely identify users?

If you log into a platform (Twitch, Blizzard, Steam, Most Crypto exchanges, Most Banks) from a new device you'll typically get an email stating so.
As far as my knowledge goes, the only information you can get on a request is
IP address
Device Operating system & version
Browser type & version
Are these platforms basing their "unique" users off of this information alone and/or am is there more information that can be gathered?
From a security perspective the largest thing is your identity or how you authenticate. That's king. The email stating "hey this is a new device" I've seen handled differently from site to site. Most commonly it's actually browser cache and I see banks specifically use browser cache to store these kinds of tokens. Otherwise every time your cellphone connected to a new cell tower you'd likely be flagged as different. They're not necessarily the same as an authentication token, rather it just says hey I've authenticated as this user to this site before. Since it's generated by the service provider, the service provider knows to trust it, and it's nearly impossible to hack (assuming it's implemented correctly).
From my own experience the operating systems and browser types, that's more record keeping than actionable insights, however you could build a security system that takes into account an IP address from very different geo-locations. I.e. why is this guy from the US logging in from China. They just logged in from California 3 hours ago, this is impossible. I don't believe most sites really go to that extent though. I do see MFA providers saying "hey there's a login from china, do you want to approve?". That workflow makes a lot more sense.
The last part of your question is tricky, regarding "unique users." Most calculate that based off the number of sessions opened (tabs), or in the case of Twitch (since you mentioned them specifically), the number of tabs that are streaming that video in. These open platforms where anyone without an account can stream the content obviously treat this differently than say Netflix that makes you authenticate and each account has a limited number of sessions that can be open.
AFAIK, most of the systems like this stores a cookie in your browser when you log (not the session cookie, just a random ID) that is also assiciated to your account in the provider database, so when you came back, you log in, and they check whether you have that cookie set and in case if the ID matches
They you can probably do some more advance stuff with that ID, like base that value from the browser, OS, expire date and so on

User XXX is not allowed to access URL

I have successfully installed liferay 7 and configured CAS 3.6 for SSO. Everything is working fine. I was able to create users, assign roles, create pages etc etc.
After few days, I was trying to create a new user via admin, I got warning "User 30810 is not allowed to access URL https://mysite:8443/group/control_panel/manage and portlet com_liferay_users_admin_web_portlet_UsersAdminPortlet". I could not able to create user. and from then that user does not have any permission that I use to do earlier.
I googled a lot on this, got few suggestions like
1) Adding below in portal-ext.properties:
redirect.url.security.mode=domain
redirect.url.domains.allowed=*.mysite.com
session.timeout.warning=0
session.timeout.auto.extend=true
2) Some links:
https://web.liferay.com/community/forums/-/message_boards/message/92226678
3) Somewhere it is mentioned that this it is bug with liferay started from liferay 7 GA4
4) If you read the link, it is mentioned that it related to Guest user and session expiration that starts causing this issue etc.
Had any one gone through this issue? Is there any solution or workaround for this?
I could not able to update this question with all the option I tried or solutions that is mentioned on google or liferay's official jira sites however I will keep updating this question with proper references.
Meanwhile
Do provide your suggestions/solutions.
"this starts happening when some session automatically logs out"
This phrase tells me several things, like the possibility of an user logging out even though you set "session.timeout.auto.extend".
Two basic scenarios where this can happen is:
When you close your tabs, after the assigned timeout, the user will be logged out. And when you got back, especially after a browser crash or using the back button, your browser used old data.
When you have the auto session extension working with a big timeout, leading to the possibility that the session timeout configured in Liferay being bigger than the one configured on the server.
On the last case, one might be interested on completed the config you exposed with short timeouts.
session.timeout.warning=0
session.timeout.auto.extend=true
session.timeout=5
session.timeout.redirect.on.expire=true
I know it is an old thread but it may help someone...
The "extend session" functionality is not working correctly and the final user session is expired, so when they try to log in, they have the wrong CSRF token from the previous session:
You have to double-check that the session.timeout Liferay portal.properties has the same value as the session timeout configured in your application server.
You have also check that the session.timeout.auto.extend.offset is greater than 60 seconds to avoid having problems with the chrome javascript intensive throttling

Suspend / disable a particular email account. Linux whm cpanel

My problem with one email account is not incoming / outgoing spam, that I could manage. It's the Brute Force attempts. My csf and cphulk take care of the attemps already, BUT its like 10 attemps per second from VERY different IPs.
So only solution I can think of is temprorarily disabling / suspending the said email account. But I cant find a way to do this via whm linux or cpanel.
Apparently it's already a feature request for whm/cpanel: https://features.cpanel.net/topic/disable-email-account
The only thing i found close to a solution was this: http://cpanelplesk.com/disabling-an-email-account-in-cpanelwhm/
But I dont know if It would work, and if its the right way to do this. Any opinions ?
You can not disable/suspend any single mail account on cpanel server, As per the above URL you can prevent outgoing email from the single account. But you are getting invalid login attempts issues so that will not help you on this.

Meteor Accounts autologin pattern?

I'm thinking about a sign-up-with-mobile number system whereby someone can register with a mobile number and get a SMS to verify that they exist... at which point I'd like to have them automatically logged in without a password... (the SMS is basically a password)
This is patterned on the Lyft app sign-up, which doesn't ask for a username/password/etc.
But for the life of me, I can't figure out how to do this.
I'm totally fine with a server only Meteor.method which responds with something "secure" but I don't know what that would be now.
The only thing I can think of would be to set the password on the User and then transmit it to the client and run a login (which seems insecure to me).
I have read through this great article
https://meteorhacks.com/extending-meteor-accounts.html
and it's a good option, but I don't know of a strategy for that which wouldn't bypass security too
(at some point the server has to communicate securely back to the client...)
Recommendations?
I made a package that might help you, Meteor accounts phone, which do login based on sms mobile number verification https://github.com/okland/accounts-phone/ Enjoy!

IIS SMTP used to relay Contact Us form messages to Gmail has been blacklisted by Google

I have 2 Windows 2008 R2 boxes running in Microsoft Azure. My ASP.NET 4.0 site (let's imagine it's running at "example.com") has a standard Contact Us form.
When a user sends a Contact Us message, I use System.Net.Mail and SmtpDeliveryMethod.Network to deliver mail to an IIS6 SMTP server running on each box, which sends the mail to a Google Apps "enquiries#example.com" account, using the email address the user entered into the Contact Us form as the "From" address.
This was working beautifully for a year until I checked it today, and found this error in a .BDP file in the \Badmail folder:
550-5.7.1 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been blocked. Please visit http://www.google.com/mail/help/bulk_mail.html to review our Bulk Email Senders Guidelines.
Obviously Google upped their anti-spam strategies in the last 6 months - last time it worked was Feb 2013 (yeah, we don't get much mail luckily... yet).
I've read the Bulk Senders Guidelines linked above, but they're not really suited to my use case. My case is not sending emails from our server to users of our site (I simply use the Gmail API and send from our enquiries#example.com for that), but rather to collect users' enquiries so that we can easily respond by clicking Reply in that inbox.
I am looking for the easiest solution here. In response to the ones in Google's Bulk Senders Guidelines:
Use a consistent IP address to send bulk mail: I already do, doesn't seem to help
Reverse DNS: Godaddy, my domain and DNS provider doesn't seem to support them: http://support.godaddy.com/groups/domains-management-and-services/forum/topic/how-do-i-setup-reverse-dns/ Anyone know if there's a way?
Use the same address in the 'From:' header on every bulk mail you send: This is totally not my use case. I'll have different From headers in every email
SPF record: I think this only works if I am sending From ...#example.com every time. Is that right? My feeling is SPF doesn't help me here. Would love someone to enlighten me.
DKIM: This looks hellishly complicated, but I'll pursue it if someone thinks it can work in this case. Specifically is it OK that the From address doesn't match the "signing domain"? Anyone got any good "how to" links? And will this be sufficient for Google to un-blacklist me?
Sendgrid: Azure's preferred mail sending app. This means signing up, code changes, testing, and unknowns like "does Sendgrid allow any From address? It's non-trivial, and I'd like to avoid this, but again, will go there if it's what people think is the sanest option.
As a general answer to your questions, sending email on behalf of many different domains from one IP (e.g. example.net, example.org, and ex.co from 10.0.0.1) is generally seen as spammy behavior (and therefor not recommended).
Your points 1-5 only apply if you're sending from one domain. rDNS, SPF, and DKIM only improve delivery for one IP to one domain (in a generally 1:1) relationship.
Generally, the best way to avoid getting marked as spam in a situation like this is to set the From email as a consistent one that you actually control (e.g. enquery-sender#example.com), and then setting the Reply-To as the entered address (e.g. enquirer#someprovider.com). This way you consistently send from one domain, while still getting the benefit of replies going to the message originator (for example LinkedIn does it this way). Doing this will allow you to setup rDNS, SPF, and DKIM with benefit.
That said, if you decide that you don't want to use the recommended Reply-To method, you can use SendGrid to send from any arbitrary domain. It should not require any significant code change (just switching your current SMTP credentials to SendGrid's).
Disclaimer: I am a SendGrid employee.

Resources