ᴺᴱᵂ ᴾᴸᵁᴳᴵᴺ 🐝 IP Checker | Detect VPN and Proxy usage, as well as bad IPs


IP Checker



Check VPN use and IP quality

Hi there!
We just release this new plugin to the Bubble marketplace :honeybee: !

→ Detect the use of VPNs/Proxys and check the quality of the user’s IP address to prevent fraud.

:arrow_right: Detect VPN and PROXY use
:arrow_right: Check any IP risk level
:arrow_right: Detect iCloud proxy use
:arrow_right: No request restrictions or quotas
:arrow_right: Perform checks on custom IP addresses
:arrow_right: Based on AI and a billion IP addresses database
:arrow_right: Continuously updated
:arrow_right: Made in collaboration with GetIpIntel
:arrow_right: No API key or third-party account required





Hey @vnihoul77

I noticed when you use the “Trigger IP address” action in a workflow you can’t get the Result of that step to fill in IP address info in a step after it.

If you use the Trigger action then in your next step fill in the IP Address element’s value it’s not necessarily retrieving it in time and still results in a blank value

EDIT: Well I think this is the wrong plugin page I’m referring to this one 🐝 IP Address Complete #Geolocation Plugin | Bubble
But maybe you can still help me :joy:

Hey @tylerboodman - some general notes about element plugins (and I know you’re not referring to @vnihoul77’s plugin , but):

This feature is not available to plugin developers in either the element or client-side action plugin API’s. So there are no third-party plugins that can do this.

What they do instead (for element plugins) is publish the value(s) that result from some element action to an exposed state. Because this is all they can do. (I have made repeating entreaties to Bubble to enable such functionality in the client-side actions API [and, by implication, the element actions API as well], but this is something that’s not available yet. Though it might be something we see added early next year, if this can be trusted.)

Right, in many instances (which are hard to fully document because it really seems to “depend on a lot of reasons”), the exposed state may not be available yet to certain downstream in-the-same-workflow actions by the time Bubble decides to trigger them.

What a well-built plugin will do is trigger an event after the exposed state values are published to that the Bubble programmer can key off of that event and continue with actions that need access to the published values. (You may want to check if the plugin you are using offers such an event - sometimes these are present but not documented in any meaningful way.)

But of course this is neither documented nor required, but it’s a best practice that more experienced Bubble plugin devs are familiar with. If our element plug has an action Blah, we would publish the results of Blah to the element’s “Blah Results” output (exposed state) and then trigger an event like Blah Complete. In Bubble element API code:

instance.publishState('blah_results', results)

And you would use that triggered Event (which appears in the editor under Workflow triggers as “Blah Complete”) to continue doing something after But not all plugins are designed this way.

If such an event isn’t available, you can (particularly if you’re only using the action in question once), create a workflow that triggers on the “when some condition is true” type workflow trigger on when “such and such plugin’s exposed state” is not empty. This will go true when that output goes from its initial state (which is typically empty) to being populated.

If you’re using such an action (which has no triggered event) multiple times, this becomes a bit more problematic, but you can watch for changes to the exposed state in various ways (one great way to do that is with the Floppy Expression Watcher element).

In recent times, a bit of not-entirely-untrue (but also not-entirely-true) Bubble folk wisdom has sprung up that if you encapsulate some workflow actions that act synchronously with respect to one another in a Custom Event, and then follow that with another Custom Event that also contains actions that are synchronous with respect to each other, that the whole chain will then be synchronous.

But, this is not true in all cases, as I observe in this video and subsequent discussions. Until we have a proper way of returning values from a plugin action to the workflow (meaning that not only can we return values to the workflow from plugins, but that the presence of a value in “Result of step x” is actually respected), there won’t be an elegant, universal solution to the issues you’re facing.

Note that server-side actions do return values to the workflow and using such “Results of step” do in fact enforce synchronous operation of downstream actions that depend of those values, but that’s the only context in which we have access to that feature. (And, obviously, server-side actions are not appropriate for most in-page type things we might do with plugins.)

I had no idea the actions couldn’t have a Result of step but that makes so much sense considering every plugin has that exposed state like you say. Hopefully the return value feature gets added like you’ve been asking for…

Thank you as usual!

@vnihoul77 now that @keith has pointed it out I do see the Event/exposed state when the IP address is ready, disregard what I was asking for :slightly_smiling_face:

1 Like

@tylerboodman, the head-bashing-on-the-desk with Bubble is endless. Just when you graduate to what seems like the next level, you discover a whole new set of “WTF” to go through the various stages of grief over. :crazy_face:

1 Like


Happy you found your way @tylerboodman !

1 Like