URL activity / plugin: Using variable or non-http(s) prefixed input?

URL activity / plugin: Using variable or non-http(s) prefixed input?

by Peter Willendrup -
Number of replies: 3

Hi there,

(Sorry if this post has ended up in the wrong place, I am not sure whether my question is mostly Activity, Plugin or Moodle system relevant...)

I am using Moodle 3.7.1 in a setup with other web-driven services, running on nginx served by a Debian 9 Linux.

Historically we have been deploying all the related services on the same piece of hardware, including a mediawiki, a physics simulation engine etc. served such that

  • https://servername/moodle served our Moodle courses
  • https://servername/wiki served our Mediawiki
  • https://servername/sim served our simulation service

Moodle has generally been the anchor point, i.e. where we would use the URL activity (and other methods) to link to the other external resources. 

Going forward, these services may end up on separate web hosts, and it would be good to have a way to define say

$CFG->wikihost; 
$CFG->simhost;

that could be referred to from the URL activity, allowing to change these centrally rather than specifying a FQDN with http(s) prefix in every case.

My question is two-fold:

1) When entering the URL's how can one bypass the test done to require a prefix of http(s):// ? (The below image shows that an 'Enter a URL' warning/error is raised when clicking to save a URL not starting with http(s)://, i.e. /wiki)


Image showing that 'Enter a URL' is raised when trying to save a non-http(s):// prefixed value

2) Is there a way to refer to centrally-defined variables such as $CFG->wwwroot from the URL activity / plugin?

Best,

Peter Willendrup




Average of ratings: -
In reply to Peter Willendrup

Re: URL activity / plugin: Using variable or non-http(s) prefixed input?

by Ken Task -
Picture of Particularly helpful Moodlers

As you know moodle internal links are not relative ... takes wwwroot config variable and adds that.  Reason ... improved security.

Having said that, however, what happens if you click the 'Choose a Link' button?

If you, the admin, enters a link for http:// or https:// your own wiki or wordpress or whatever, is that available to other users using the 'Choose a Link' button?

I can foresee a problem leaving a dialog box open to users and expecting users to get the input correctly entered ... either by mistake or a user just 'tinkering' ... 'let's see what will happen, if ....' (my background ... plenty of experience helping admin Moodles for K12 world and a programmer of an online workshop registration system backended by FileMaker Pro).

Generally, leave an input box not sanitized/checked after user input and that can have very strange (maybe even harmful) results. :|

'SoS', Ken



Average of ratings: -
In reply to Ken Task

Re: URL activity / plugin: Using variable or non-http(s) prefixed input?

by Peter Willendrup -

Hi Ken,

Thanks for the feedback - sure, I understand the security concerns. And sure, completely bypassing sanity-checks would also be stupid.

The workaround applied thus far was to directly massage the URL strings in our mysql database which on the other hand also is a bit wonky...

Using the 'Choose a Link' options sounds possible, sorry for my moodle - unawareness, but how does one populate that menu? The items I see in there seem related to the 'Repositories' plugin in the admin settings.

Best

Peter

Average of ratings: -
In reply to Peter Willendrup

Re: URL activity / plugin: Using variable or non-http(s) prefixed input?

by Ken Task -
Picture of Particularly helpful Moodlers

Hmmmm ... didn't mean to sound like a developer ... am not.

From 'informed users view' ... 2 approaches to adding a 'feature' to Moodle UX:

1. develop a plugin or 2. find a work-around

My suggestion was #2 above ... "what would happen if..."

If you as admin, added http(s)://yoursite/wiki/ would/could other faculty/student users choose same option and see your entry to use? 

For admin ... with DB access ... find the tables where those are stored and manually enter row.

Developing a plugin is involved ... and then there is maintenance to changes in code when Moodle core moves upwards.  One can find many plugins in the Moodle 'store' whose development ceased and are no longer compat with newer versions of Moodle.

And there's another approach for developing ... find a plugin that's close to what you want ... clone it as a new plugin.  Develop.  Install ... stated oh so simply ... not so simple, however.

'SoS', Ken

Average of ratings: -