This object is in archive!
cPanel Path Customization
Completed
I request a feature in order to be able to customize the cPanel URL/Path (domain.com/cpanel) for security reasons as a high priority. I believe it is better when every website has its own path to the control panel. Users don't have to know what control panel running on the server or what its URL.
Thank you.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
This is something that would require some re-engineering of the product to accommodate. There are many URLs and functionality within the product that rely upon /cpanel /whm and /webmail being constant. There are also 3rd party scripts and bundles that rely on this being there. This could therefore break quite a lot, especially if your desire is to have this alias customized per-domain and/or per-user.
The proposition of this being from the grounds of security is also concerning. This would be an example of security through obscurity, which should never be anywhere near the top layers of protection from malicious behavior. Security through obscurity is simply hoping and keeping fingers crossed that the attackers don't find the service at all. Since cPanel & WHM is intended to be a visible and prominent service, this seems counter-intuitive and would result in much client frustration. There are also a multitude of avenues to follow to discover if a server is utilizing cPanel & WHM, and obscuring the /cpanel alias would not really assist in obscuring the existence of cPanel.
The ideal route is to ensure everything is truly secured. If you have any security concerns you're aware of which can be abused, please immediately post them to security@cpanel.net for further review and response.
I'd like to hear further feedback on this and use-cases for why it would be desired, but this feature under the grounds of security seems like a pretty shaky reasoning. As mentioned, security through obscurity is generally the last thing that should be considered as a form of protection. This is especially with a service thats intention is to be well known and visible to the customer.
I could see this introducing significant frustration to the user experience.
This is something that would require some re-engineering of the product to accommodate. There are many URLs and functionality within the product that rely upon /cpanel /whm and /webmail being constant. There are also 3rd party scripts and bundles that rely on this being there. This could therefore break quite a lot, especially if your desire is to have this alias customized per-domain and/or per-user.
The proposition of this being from the grounds of security is also concerning. This would be an example of security through obscurity, which should never be anywhere near the top layers of protection from malicious behavior. Security through obscurity is simply hoping and keeping fingers crossed that the attackers don't find the service at all. Since cPanel & WHM is intended to be a visible and prominent service, this seems counter-intuitive and would result in much client frustration. There are also a multitude of avenues to follow to discover if a server is utilizing cPanel & WHM, and obscuring the /cpanel alias would not really assist in obscuring the existence of cPanel.
The ideal route is to ensure everything is truly secured. If you have any security concerns you're aware of which can be abused, please immediately post them to security@cpanel.net for further review and response.
I'd like to hear further feedback on this and use-cases for why it would be desired, but this feature under the grounds of security seems like a pretty shaky reasoning. As mentioned, security through obscurity is generally the last thing that should be considered as a form of protection. This is especially with a service thats intention is to be well known and visible to the customer.
I could see this introducing significant frustration to the user experience.
This is something that would require some re-engineering of the product to accommodate. There are many URLs and functionality within the product that rely upon /cpanel /whm and /webmail being constant. There are also 3rd party scripts and bundles that rely on this being there. This could therefore break quite a lot, especially if your desire is to have this alias customized per-domain and/or per-user.
The proposition of this being from the grounds of security is also concerning. This would be an example of security through obscurity, which should never be anywhere near the top layers of protection from malicious behavior. Security through obscurity is simply hoping and keeping fingers crossed that the attackers don't find the service at all. Since cPanel & WHM is intended to be a visible and prominent service, this seems counter-intuitive and would result in much client frustration. There are also a multitude of avenues to follow to discover if a server is utilizing cPanel & WHM, and obscuring the /cpanel alias would not really assist in obscuring the existence of cPanel.
The ideal route is to ensure everything is truly secured. If you have any security concerns you're aware of which can be abused, please immediately post them to security@cpanel.net for further review and response.
I'd like to hear further feedback on this and use-cases for why it would be desired, but this feature under the grounds of security seems like a pretty shaky reasoning. As mentioned, security through obscurity is generally the last thing that should be considered as a form of protection. This is especially with a service thats intention is to be well known and visible to the customer.
I could see this introducing significant frustration to the user experience.
This is something that would require some re-engineering of the product to accommodate. There are many URLs and functionality within the product that rely upon /cpanel /whm and /webmail being constant. There are also 3rd party scripts and bundles that rely on this being there. This could therefore break quite a lot, especially if your desire is to have this alias customized per-domain and/or per-user.
The proposition of this being from the grounds of security is also concerning. This would be an example of security through obscurity, which should never be anywhere near the top layers of protection from malicious behavior. Security through obscurity is simply hoping and keeping fingers crossed that the attackers don't find the service at all. Since cPanel & WHM is intended to be a visible and prominent service, this seems counter-intuitive and would result in much client frustration. There are also a multitude of avenues to follow to discover if a server is utilizing cPanel & WHM, and obscuring the /cpanel alias would not really assist in obscuring the existence of cPanel.
The ideal route is to ensure everything is truly secured. If you have any security concerns you're aware of which can be abused, please immediately post them to security@cpanel.net for further review and response.
I'd like to hear further feedback on this and use-cases for why it would be desired, but this feature under the grounds of security seems like a pretty shaky reasoning. As mentioned, security through obscurity is generally the last thing that should be considered as a form of protection. This is especially with a service thats intention is to be well known and visible to the customer.
I could see this introducing significant frustration to the user experience.
The /cpanel url to login to your control panel is a well established convention. Removing, or changing, it for the sake of obscuring the access point breaks the established convention. As Brian stated, I see this as adding confusion without creating any business value.
The /cpanel url to login to your control panel is a well established convention. Removing, or changing, it for the sake of obscuring the access point breaks the established convention. As Brian stated, I see this as adding confusion without creating any business value.
Replies have been locked on this page!