WebSite X5Help Center

 
Antal Z.
Antal Z.
User

Secure login - Login & Logout - Admin 2019.1. x  en

Auteur : Antal Z.
Visité 2084, Followers 1, Partagé 0  

Secure login - Login & Logout - Admin

The program provides secure e-mail sending to send mail or datasheets.

Why can't I assign secure access to the "admin" interface and the "Login & Logout" object?

How do I enable secure access to these entry interfaces?

Login & Logout

This lets users log in/log out so they can access locked pages in your website.

Link: https://market.websitex5.com/en/objects/live-preview/331c1bf7-12ef-43d8-b329-352d615dfec

Admin interface

Why use only spam protection?

Posté le
5 RéPONSES - 1 UTILES
Paul M.
Paul M.
Moderator

Hello Antal,

What are the perceived risks which you are trying to guard against?  Can you be more specific please by what you mean by "secure access"?

WebSite X5 can only contribute so far in terms of site security.  The server (and your webhost) play a far bigger role overall.

Using SSL certificates and locking down the server with good use of .htaccess files, setting file and directory permissions correctly, blacklisting rogue IP addresses...  there are many things which can be done to protect a webspace.

But what in particular are you trying to mitigate against?  If we have a clearer idea then we can proffer possible solutions to suit.

Kind regards,

Paul

https://webx5.pro

Lire plus
Posté le de Paul M.
Antal Z.
Antal Z.
User
Auteur

Hello Paul M.

I would like to let Google reCaptcha or "Login & Logout" set a time limit on login when the user logs in.

Lire plus
Posté le de Antal Z.
Paul M.
Paul M.
Moderator

Go to Step 3 Sitemap Creation... highlight the page you would like to set a time limit on in the Map, then click on the Properties button on the toolbar above.

In the new screen which opens enter the following line of code on the Expert tab, Before closing the HEAD tag, as shown in the screenshot below:

<meta http-equiv="Refresh" content="15;URL= https://google.com" />

You can replace the URL with any of your choice...  this is the page that the visitor (hacker?) will be redirected to.

The value of '15' is the length of time in seconds before the redirection occurs.  Again you can alter this to suit your preference.

Lire plus
Posté le de Paul M.
Antal Z.
Antal Z.
User
Auteur

Thank you very much for your help. I didn't mean that.

Restrict Entry Experiment

3 incorrect passwords / 10 minutes can not enter
3 incorrect passwords / 20 minutes of inactivity
3 incorrect passwords / 40 minutes can not enter

Lire plus
Posté le de Antal Z.
Paul M.
Paul M.
Moderator

Thank you, I understand better what you would like to do now, Antal.

As you have noticed, WebSite X5 does not incorporate such functionality at the present time.  So I have set this thread as an 'Idea' which will enable the Incomedia developers to keep track of it and consider it for possible inclusion in a future release of the software.

However, there are good reasons why such blocking should be implemented at server level rather than application level.  Blocking at server level enhances the security even further...  it is after all the gateway to your webspace.

A popular method of doing this is to use Fail2ban:

https://devops.ionos.com/tutorials/set-up-fail2ban-to-protect-an-apache-web-server/

If you were really determined to effect the blocking using code generated from WebSite X5 then you could use a PHP script.  WebSite X5 is extremely flexible in allowing PHP code to be added almost anywhere inside a project.  There are many free example scripts available on the internet, such as the following:

http://webcheatsheet.com/php/blocking_system_access.php

The other thing to think about here is whether blocking for a limited time period is actually the best way of going about things.  A legitimate user will be aware of their access credentials, but even if they should forget them then a simple 'forgot password' link will enable them to recover via email (WebSite X5 already includes this feature).  A genuine web visitor should require no more than say, three login attempts, which would generously allow for a slip of the fingers when inputting credentials.  There is no valid reason why their IP address should not be banned after the third failed attempt, after which access to the site is denied completely until contact has been made with the webmaster/site owner.  This is a neater, more elegant scripting solution, and is even more secure because it denies any malicious hacker the opportunity to use the login page as a battering ram over and over and over again, albeit with short delays in between times.

Lire plus
Posté le de Paul M.