Forum Replies Created

Viewing 15 replies - 421 through 435 (of 574 total)
  • Plugin Author tbenyon

    (@tbenyon)

    @rapideyemovement Looking forward to hearing from you 🙂

    Plugin Author tbenyon

    (@tbenyon)

    Hey @rapideyemovement,

    Apologies for not understanding first time.

    I presume my new feature may solve your problem. It allows you exclude certain users based on a field in the database.

    Settings example here:
    https://ibb.co/jVNDWKf

    I class it as a Beta feature as it’s new but mostly because of how the settings page works for it. It was quite a large re-write.

    If you try it and it does work I’d appreciate the feedback so I can use that as evidence to strip out the “Beta” label.

    If you have any more questions don’t hesitate to get back in contact.

    Thanks,

    Tom

    Plugin Author tbenyon

    (@tbenyon)

    Hey @rapideyemovement,

    If I understand you correctly this functionality is supported.
    It’s in the role settings section.

    Image below:
    https://ibb.co/PgwwQ08

    If this solves your problem and this works for you I’d be really grateful if you could take the time to write a review.

    Thanks,

    Tom

    Plugin Author tbenyon

    (@tbenyon)

    You’re right about the default data. WordPress for example expects an e-mail address so if a user tries to update their user in the admin area they are forced to add one (even if the external system doesn’t support them).

    There is definitely an issue where different user data is stored in different tables. The plugin doesn’t currently support this and I imagine this could be a hugely complex integration. There is a risk of creating an overly complicated UI when most users will have all user data in one table. I have been asked for this feature before but I just think if at that point users may be better coding their own solution. Criticism welcome on this thought.

    I’ve never heard of SRP or other such systems but just had a quick read and it sounds cool. You would need to add the admin verifier to that options section. You’d then need to hide fields that weren’t relevant to that option.

    I think the only files to modify would be:

    • validate_password.php – to accommodate for your custom SRP system
    • Exlog_built_plugin_data – to update the options required. If you need more field control or other field types other files may need updating. PELASE NOTE – I’ve just realised that options_fields.php is no longer used in the plugin and the deactivation hook is not working correctly because of this. Something to add to my backlog! It also looks like BuiltPluginData.php is a duplicate that needs removing.</li
    • db.php – for all the querying
    • Welcome to bring them up issues either here or on Github.

      I would love to work with you more closely with this but I just don’t have the time to work on a project of this size at the moment. I am however of course happy to answer questions and discuss options with you. Just want to be upfront about what I can realistically offer. I’m investing my time in learning automated testing for the plugin at the moment.

    Plugin Author tbenyon

    (@tbenyon)

    I use the core WordPress filters so there should be no ill effect for you unless the plugin you are using has broken core filters or actions.

    It sounds like from your other question that you’ll be re-writing the only functionality my plugin uses wpdb directly so it shouldn’t have any impact here either.

    In short, it should work fine if the other plugin you are using has correctly integrated with WordPress.

    If you do have any issues I’m happy for you to share them here and I’ll see if I can help 🙂

    Thanks,

    Tom

    Plugin Author tbenyon

    (@tbenyon)

    Hey @kevent,

    You ceraintly could do that. All the database logic should be in that file for that very reason. It does need tidying and I want to use a PDO to add better compatibility and less work for me. 😛

    I would be really cool to help this work for others by making a pull request when you’ve got it working so others could make use of your work.

    No pressure to.

    I’m happy to support you with this if you have any more questions.

    Thanks,

    Tom

    Plugin Author tbenyon

    (@tbenyon)

    Hi @nnamellu,

    The plugin is currently built for database integration only.

    Making this work completley depends on the API that you’re using. Is it a standard authentication system or a custom one?

    I could add some hooks that would allow you to integrate but I would need to know more about how your auth system works.

    Tom

    Plugin Author tbenyon

    (@tbenyon)

    Hey @kevent,

    Although people have found me before on Facebook or LinkedIn, I am not able to give out my details here as it breaches WordPress’ terms of service.

    I apologise for not being able to give you these details, I would like to have been able to help you further.

    If you want to do the work yourself and need some advice I am more than happy to answer questions.

    In regard to this question though I feel I have answered it so will mark this as resolved.

    Please don’t hesitate to re-open this ticket or create a new one if you want more help.

    Thanks,

    Tom

    Plugin Author tbenyon

    (@tbenyon)

    Hey @dasza

    As you can see from this screenshot there are two ways to block access to certain users. One is to block them based on there roles. The other is to block them based on another field in the database.

    https://ibb.co/F8z4Q1f

    If you have anymore questions please don’t hesitate to get back in contact.

    Thanks,

    Tom 🙂

    Plugin Author tbenyon

    (@tbenyon)

    Hey Pierre (@p1erstef),

    Really appreciate the feedback. Not only coming with a problem but a solution! The best kind of user 🙂

    I will try and replicate and update this over the next week and get another release out.

    Really appreciate you taking the time to share and also for writing a review 🙂

    I’ll leave this ticket open until I get the fix in.

    Thanks again,

    Tom

    Plugin Author tbenyon

    (@tbenyon)

    Hey @fltdarryl,

    Haven’t heard from you for a bit so assuming you’ve got this all sorted.

    If this isn’t the case please message back but for now I’ll mark this issue as resolved.

    Thanks 😊

    Tom

    Plugin Author tbenyon

    (@tbenyon)

    I haven’t heard from you Daniel so I’m assuming this is now doing what you wanted.

    For this reason, I will close the ticket. If you need any support for this, please don’t hesitate to re-open the ticket and I will continue to support you 😊

    Thanks,

    Tom 😊

    Plugin Author tbenyon

    (@tbenyon)

    Hey @mikelukins,

    I really appreciate you taking the time to write a review and I’m also grateful for the beer money.

    Made my day.

    Thanks for being awesome 😊

    Tom

    Plugin Author tbenyon

    (@tbenyon)

    No problem 🙂

    Let me know if it is something you’d like to go ahead with or you have another idea.

    Thanks,

    Tom

    Plugin Author tbenyon

    (@tbenyon)

    Thanks for contributing @geckonet. You’re kind of right. I don’t think the word deprecated is what you’re looking for though. It’s more that sha1 just shouldn’t be used for password hashing. It’s not secure for your users due to the fast speed that it can be hashed which makes brute force attacks far more viable.

    I’ve written a bit more about this and linked to a great article in the plugins description if you want to read more.

    @fltdarryl – The good news is that the hash I store in the WordPress database is more secure but this still leaves your old system worth upgrading at some point.

    Again, let me know what you think of the suggested fix to your problem mentioned earlier.

Viewing 15 replies - 421 through 435 (of 574 total)