Is it possible to also restrict front-end pages with the {% requireLogin %} tag?

Currently the plugin works with an array of IP address/range values. Perhaps a future idea would be for the Restrict plugin to have a settings field that can store IP addresses.

My initial thoughts would be a multi line text field where each IP address/range would be separated on a new line. I feel there would need to be additional validation to make sure each line contains a valid IP address/range before being committed to a settings field.

It feels like a site administrator should be able to throw a 403 error rather than just do a 302 redirect over to a normal page. Would you be interested in a pull request for this? Thought would be that out of the box it would work as it does now (to maintain backwards compatibility), but if they set a config bool of throw403 or something like that, then we could throw a normal 403 exception that can be handled by 403.twig / error.twig, etc.

I have a global field that contains IP address/range values. It's actually using the tag fieldtype but customised to represent IP addresses and labels. I'm pointing the returned values to the ipWhitelist config value. However this seems to be having an interesting side effect, where by it makes returning other non related global values elsewhere as NULL (mainly text fields, entry/category fields seem OK). It's definitely related to the restrict.php config as if I disable the restrict plugin the problem goes away, if I then remove my custom config that uses the global and keep restrict enabled, the problem also goes away, so it seems calling Craft::$app->globals in restrict.php is the issue, however I'm not sure why this breaks.

I did find some related info about this:

craftcms/cms#3028
nystudio107/craft-seomatic#108

In a Craft 2 project I use this plugin to whitelist the CP to a set of IP addresses within our organisation and a few individuals, these were a combination of single IP addresses as well as "ranges". I ended up hacking in support for ranges by basically making the plugin aware of the "*" character using regex so something like 192.168.* would match all IP addresses beginning with 192.168.

It would be nice if this could be possible in the Craft 3 plugin. Performance wise I'm not sure the regex approach is ideal for large amounts of IP addresses. It would probably be better to handle CIDR notation like 192.168.0.0/24 or similar, but this would require a fair bit of work hence the feature request!

I just added the plugin to a Craft site running 3.4.22.1
I added the IPs as listed
'ipWhitelist' => [ '::1', '127.0.0.1', '00.000.000.000', '00.000.000.000', '00.000.000.000'],

But none of the users can access the backend. We cleared the site cache but we are still getting blocked.
Our file is in /config/restrict.php

Any suggestions?

@sjelfull It occurred to me I never followed up regarding your comment on #5 (comment). How rude of me, apologies.

So I looked into the issue a bit more, so the scenario can be in some cases when using the template option and pointing to a template that uses extends that may reference other plugins i.e. twig filters etc, you will get an error when Restrict tries to render the template, because it won't exist at that time.

In the plugins init function, if you change the existing check service call to:

Event::on(
    Plugins::class,
    Plugins::EVENT_AFTER_LOAD_PLUGINS,
    function () {
        if (Craft::$app->getRequest()->isCpRequest) {
	    $this->restrictService->check();
        }
    }
);

This fixes that problem and allows the rendering of the template to continue, as it's now being loaded after everything else. However, I think some further thought is needed around:

https://github.com/sjelfull/craft3-restrict/blob/master/src/services/RestrictService.php#L88

Fixing the potential race condition shows that the head and footer section of the specified template do not get parsed, instead we see the placeholders: https://github.com/yiisoft/yii2-framework/blob/master/web/View.php <![CDATA[YII-BLOCK-HEAD]]> and <![CDATA[YII-BLOCK-BODY-END]]>. The makes sense because it's simply being echo'd without any Yii awareness in this regard.

Wondered what your thoughts are?

Thanks!

Tried porting this plugin with existing configuration from Craft 2 to Craft 3 - behavior seems to be the opposite of what is advertised i.e. site is only accessible if you are logged in to Craft through the CP