Andrew Sassoye
My feedback
30 results found
-
6 votesAndrew Sassoye
supported this idea
·
-
16 votesAndrew Sassoye
supported this idea
·
-
26 votes
This is a valid request, so we’ll look into it. There is no ETA at the moment, but we would really appreciate you voting for this request so that we can accurately assess its popularity relative to other features. Thanks in advance!
— rk
Andrew Sassoye
supported this idea
·
-
26 votes
Thank you for your input! We will consider this functionality in upcoming releases if it will be popular.
Everyone, please continue voting for this feature if you consider it important.
—
IGAndrew Sassoye
supported this idea
·
-
26 votes
Thank you for your input! We will consider this functionality in upcoming releases if it will be popular.
—
ETAndrew Sassoye
supported this idea
·
-
24 votes
In the initital feature request it was not clear that the focus was on a regex driven, variable redirect that depends on source URLs and should be able to provide a mapping between source and target. It is also requested that these redirects shall be done on the front-end web server level, not as an Apache .htaccess solution.
We have re-opened the request as per user comment it was clarified thoroughly. We will consider this functionality in upcoming releases if it will be popular.
Everyone, please continue voting for this feature if you consider it important.
-- PD
Andrew Sassoye
supported this idea
·
-
74 votes
Thank you for your input! We will consider this functionality in upcoming releases if it will be popular.
Everyone, please continue voting for this feature if you consider it important.
— rk
Andrew Sassoye
supported this idea
·
-
48 votes
Thank you for your input! We will consider this functionality in upcoming releases if it will be popular.
Everyone, please continue voting for this feature if you consider it important.— rk
Andrew Sassoye
supported this idea
·
-
93 votesAndrew Sassoye
supported this idea
·
-
94 votes
Thank you for your input! We will consider this functionality in upcoming releases, if it will be popular.
Everyone, please continue voting for this feature if you consider it important.-DL
Andrew Sassoye
supported this idea
·
-
556 votes
We have serious doubts this function can really increase server security:
1) Plesk has built-in protection against brute-force on login – it will lock the login form. So no one can try multiple attempts
2) Arbitrary login name adds very little guess-complexity to a proper password. If you have concerns for your login brute-forced – add another 5-7 characters into your password and feel safe.As changed login name is still very likely to be some sort of vocabulary word or derived from your other account name – this function would only give a false sense of better security. Your security strength is in complex password, not in a complex login name. If you have one good password, you don’t need to treat login as your “second password” – one good password is enough.
As for concerns that default password requirement is set in “weak”, that fail2ban module is not…
Andrew Sassoye
supported this idea
·
-
378 votes
As UserVoice staff cleaned up the most of twisted voices, I’ve returning this suggestion to open discussion.
Everyone, please continue voting for this feature if you consider it important.
—IB
Andrew Sassoye
supported this idea
·
-
806 votes
Would you mind to try Nginx caching in Plesk Onyx 17.8 Preview?
This would be very helpful to get your experienced feedback here http://www.surveygizmo.com/s3/4165754/Plesk-17-8-Preview
Andrew Sassoye
supported this idea
·
-
510 votesAndrew Sassoye
supported this idea
·
-
390 votes
An error occurred while saving the comment Andrew Sassoye
supported this idea
·
-
18 votesAndrew Sassoye
supported this idea
·
-
5 votes
Thank you for your input! We will consider this functionality in upcoming releases, if it will be popular.
Everyone, please continue voting for this feature if you consider it important.—
IGAndrew Sassoye
supported this idea
·
-
56 votes
Thank you for your input. We will consider this functionality in upcoming releases if it will be popular.
Everyone, please continue voting for this feature if you consider it important.
—
IGAndrew Sassoye
supported this idea
·
-
6 votes
Thank you for your input. We will consider this functionality in upcoming releases, if it will be popular.
Everyone, please continue voting for this feature if you consider it important.
—
IGAndrew Sassoye
supported this idea
·
-
99 votes
Thank you for your input! We will consider this functionality in upcoming releases if it will be popular.
Everyone, please continue voting for this feature if you consider it important.
—
IGAndrew Sassoye
supported this idea
·
@Plesk,
I don't understand this is not implemented yet. I use a single symfony app that handle multiple domains and subdomains. I can add domains and subdomains in the subscription and use the same document root, but I have many nginx and apache rules, and I have to copy and modify each one every time I want to modify a rule. I can also use the server_name rule of nginx but then I can not automatically add the (sub)domains in the let’s encrypt certificate. The wildcard option is a good option, but not in my case. Sometime I have sub.sub.domain.com, and this domain is not included in the certificate. The best way to solve this problem is to add the possibility to add a (sub)domain alias that have exacted the same rules as his parent. And when the panel create the certificate he can add the aliases in the certificate automatically (The limit is 100 per certificate). I don’t understand this discussion is open since 2014.
Regards,
Andrew