Última modificación: 24/01/2017
Problemas de sincronización y difusión en usuarios con iThemes Security instalado.
Nuestro Departamento de Soporte Técnico ha detectado varias incidencias relacionadas con la sincronización de nuevas entradas publicadas en los blogs de los usuarios, así como en la difusión por Twitter de titulares e imágenes. Y en la mayoría de los casos el causante de estos fallos es el plugin de seguridad para WordPress, iThemes Security.
Después de varias pruebas de nuestros técnicos y después de intercambiar mensajes con la empresa responsable del desarrollo de éste plugin, se ha definido un protocolo de actuación que resuelve las restricciones en la mayoría de los casos afectados.
Configuración recomendada para el buen funcionamiento de BlogsterApp en usuarios con iThemes Security instalado:
- En WordPress, ir al apartado de “Seguridad” donde aparece la configuración de iThemes.
- Hacer click en el botón “Configurar ajustes” dentro de la sección “Usuarios Baneados”.
- Desactivar la opción ”Habilitar la funcionalidad de lista negra de HackRepair.com” que aparece como “Lista negra por defecto”.
- Guardar ajustes.
Con estos sencillos pasos, tanto la sincronización como la difusión en BlogsterApp deberían funcionar con normalidad. Si no fuera así, les recomendamos abrir un ticket en nuestro Departamento de Soporte para analizar en profundidad la situación.
FUERA DE LA BASE DEL CONOCIMIENTO EN ZENDESK.
Mensaje 1 desde iThemes explicando la incidencia:
Unfortunately there isn't a way to just mark you as "trusted", because this isn't the way it works. If there was, I'd happily do so.
The specific setting in iThemes Security that results in blocking your crawler can be found in Banned Users > Enable HackRepair.com's blacklist feature. Disabling that setting will remove the block. I should note that this is not enabled by default.
The Hack Repair blacklist is a legacy feature of iThemes Security added by the previous developer. Personally, I don't find much value in it as most of the user agents listed in the HackRepair list are legitimate and are blocked, not because they increase security of a site, but because the person behind the Hack Repair doesn't like most crawlers.
Unfortunately, I cannot justify removing the rule that is blocking you from the list right now. The reason for this is that the list is mostly composed of legitimate crawlers and removing yours based on the criteria of legitimacy would result in removing nearly every crawler on the list. Since an unknown percentage of users are likely to want these types of blocks, I need to find a different way of rectifying this situation.
For the short term, I recommend that you tell users to disable that setting if they desire to use your product.
I'm working on a better long-term solution to blocking user agents. A current consideration is to split up the Hack Repair list into our own curated lists such as bots with no legitimate source or purpose and legitimate bots that users may wish to block (with details about what that means). Both lists will be optional and disabled by default. I'm also planning on downplaying the value of the lists as the real bad actors out there use user agents that cannot be distinguished from regular browser traffic.
I wish that I could give you an immediate resolution to the issue, but changes to a security product have to be well thought out and considered. Even if I don't personally like a feature or its implementation, it would be an abuse of my power as the lead developer to impose my will and perspective on all users without strong consideration of their desires and perspectives and without giving options to those various viewpoints.
Nuestra respuesta al primer mensaje:
We have met with the department's managers and first at all we want to thank you for your broad response.
However we have to tell you that we are very sorry to hear the solution you are giving us.
The problem we are raising affects people who are users or clients of BlogsterApp, meaning that they have previously trusted us and are using our product.
The solution you give us is the same as we had determine with our tests, and a lot of our clients and users do not understand this situation.
The blocking of HackRepair.com's blacklist in our application is critical, we are losing corporate and professional clients who have iThemes Security installed
and who can not synchronize the content of their blogs with Blogsterapp and also do not accept to apply the solution that iThemes give us because they think that their WordPress will be insecure.
What other alternative can we suggest to our customers?
We deeply appreciate your help and your effort to find a corporate solution to our situation.
Mensaje 2 desde iThemes respondiendo a nuestra solicitud:
If you can narrow to which rule is causing the conflict I can file the report. But as I mentioned, unfortunately at this point we can't just start removing rules, whether we want to or not. Many of our users have been using these for many years, and we have to consider this.
It is fine to ask for them to not use this one feature. The iThemes Security plugin is a DIY plugin, and not all features are going to be able to be used by everyone. I inform our own customers of this daily. It's meant for them to use as many as their environments will allow. And as now, your customers will not be able to use the Hack Repair Default Blacklist feature. There are many other very useful features including Two-Factor that will go much further in securing their sites. If they're a paying iThemes Security Pro customer, they can open a ticket with me as well.
Thanks for understanding,