Can't get Moodle to validate keys OR allow reconfiguration error, please help! about seb-win-refactoring HOT 56 OPEN

Hi @spicymoodles @abowman-unige

in HttpProxyModule in your Ngnx conf:

proxy_pass httpS://WHAT IS YOUR HOST;
proxy_set_header HTTP_X_SAFEEXAMBROWSER_REQUESTHASH $http_x_custom_header;
proxy_set_header HTTP_X_SAFEEXAMBROWSER_CONFIGKEYHASH $http_x_custom_header;

Edit: Please also make sure the underscores_in_headers is set to on (by default Ngnx doesnt understand underscores in headers) -> this option is in the ngx_http_core_module directive.

underscores_in_headers on;

Please make sure you put the right things (or ask the system admins: please allow forwarding the custom headers in Ngnx), do NOT just copy paste.

The issue:
In Moodle 2 checks happen (you are not entering allowed exam keys field, it falls back to check the headers). Because in your case, you entered the keys, then it checked the header, then validated the entered keys against hash('sha256', CURRENT_MOODLE_URL + VALID_BORWSER_KEY) <-- the only 2 case it wont match are, either white space or the current url if not matching the url entered in the config (for example, capital letters, extra ? or # etc). Please note that FULLME in moodle (ie the current url) relies on the server globals, so it can be an issue (albeit rarely).. the only way to verify if the ngnx reverse proxy is not matching, is to do (in /mod/quiz/view.php, under require_once(config.php) -> print_r($FULLME); exit;) then it would tell if that returned result is correct or not.

--
What seems to happen on your side, is that your proxy does NOT forward custom headers (namely: HTTP_X_SAFEEXAMBROWSER_REQUESTHASH , and most likely: HTTP_X_SAFEEXAMBROWSER_CONFIGKEYHASH too).

from seb-win-refactoring.

@dbuechel could you please verify that the following keys are included in the hashing calculation in 3.7

`

<key>batteryChargeThresholdCritical</key>

<key>batteryChargeThresholdLow</key>

<key>allowDownloads</key>

<key>allowUploads</key>

<key>disableSessionChangeLockScreen</key>

<key>enableCursorVerification</key>

<key>displayAlwaysOn</key>

<key>systemAlwaysOn</key>

`

from seb-win-refactoring.

Thanks for the input and further investigation. We meanwhile stumbled upon this as well internally, it indeed appears that there has been a change in version 3.7.0 which seems to cause this issue.

I shall investigate it as soon as possible and report back here.

from seb-win-refactoring.

Please note that we are using Moodle 4.1, later versions may have changed.

Thanks a lot for having a look on that issue.

from seb-win-refactoring.

An issue has been identified 2 weeks ago in moodle tracker that seems to correct this problem ?

https://tracker.moodle.org/browse/MDL-82286

from seb-win-refactoring.

@abowman-unige oh wow, it slipped through and gone unnoticed there.

This precision need to be backported to 4.1, 4.2 too to solve your problem.. a remaining problem though: others who use seb on non-moodle. they need to know about this default precision.

from seb-win-refactoring.

I did some testing with a Moodle quiz on our public demo server.

I used a configuration with default settings of SEB 3.7 for Windows, which I got from Damian (although I wonder why enableScreenProctoring is true in these settings, unless that was caused by SEB for Mac, which I used to convert the client config to an unencrypted starting an exam config).

CK calculation didn't work when these two settings were contained:

	<key>batteryChargeThresholdCritical</key>
	<real>0.1</real>
	<key>batteryChargeThresholdLow</key>
	<real>0.2</real>

When I removed those two lines from that config file and uploaded it to the Moodle quiz again, I could correctly access the quiz with SEB (CK calculation worked correctly).

Note that that config still contains these three value settings:

<key>screenProctoringImageDownscale</key>
<real>1</real>
<key>defaultPageZoomLevel</key>
<real>1</real>
<key>defaultTextZoomLevel</key>
<real>1</real>

These don't cause a wrong CK calculation, so apparently that happens only when there is a dot/fraction in the real value. This explains why this error never occurred with the two default...ZoomLevel settings, which I introduced in SEB 3.0 for macOS/iOS, but never actually used a config file with a non-default value of 1 with Moodle.

So the workaround until the calculation of the CK can be fixed in Moodle Deeper Integration would be to remove all value settings with fractions from SEB configuration files before uploading those. SEB clients will then use the default value (or a non-fraction value like 2).

Unfortunately it would definitely be too much effort to change the value types for these settings in SEB clients. Also config files saved with current SEB versions containing fractions (I guess this would mostly apply to SEB 3.7 with the newly introduced battery values) would still cause a wrong CK calculation.

Also we cannot just use string for real values. These values must be numbers, so we would need to code special cases for specific settings where strings are converted into floating point numbers. That's not the idea of SEB configuration files, we explicitly chose the plist XML format because each setting value has a fixed value type which is identifiable by the SEB client!

from seb-win-refactoring.

I think this might be resolved by https://tracker.moodle.org/browse/MDL-82286 which we have been funding a fix for

from seb-win-refactoring.

You'll need to save the configuration before copying the CK and BEK, i.e.:

1. Make all the changes required for your configuration.
2. Save the configuration file.
3. Then copy the CK and BEK and paste them into Moodle.

from seb-win-refactoring.

Hi Damian,

Thank you for the reply.

I've tried that already.
I made sure I only copy the keys at the very last step of config, as noted in SEB instructions.

I've tried copy-pasting the CK + MEK then the MEK + CK , thinking maybe the it has to be in a certain order, no luck.

I still get the same error - that the keys could not be validated. This appears on the quiz preview page, before even launching SEB. Does that mean Moodle is capable of querying the SEB client?

from seb-win-refactoring.

We encountred similar problem when uploading SEB 3.7 configuration with Moodle 4.1.9. When the seb config needed to be validated and did contain applications authorization. The problem was always there.

We did rollback with SEB 3.5 and had to redo our seb config in that version while we wait SEB 3.8

from seb-win-refactoring.

@abowman-unige To which problem are you referring exactly? I'm afraid I can't quite follow as I am not too familiar with the inner workings of Moodle itself. Is this then an issue in Moodle when a configuration contains permitted applications, or is it an issue in SEB?

from seb-win-refactoring.

Validating the key in moodle with SEB after reconfiguring itself when accessing the quiz. It only happens when we use it in moodle like this:

So we did the following steps:

1. Rolled back to SEB 3.5 (knowing that it was working from past experience).
2. Re/saved the config file in the SEB Configuration Tool in 3.5.
3. Re-uploaded it to Moodle.
4. It worked again.

We did not have time to further investigate the root cause of the problem, but we suspect an incompatibility between SEB 3.7 and Moodle 4.1.* when having some elements (apps in our case) in the SEB config file and letting Moodle calculate the key.

The problem should be on Moodle side, but knowing that it works in 3.5 and not in 3.7 we are not certain

from seb-win-refactoring.

Sometime ago someone reported a similar issue and in that case it was because of permittedProcesses in their SEB config (seems that some special characters, maybe backslash in the path of such allowed applications, cause SEB Windows to calculate a wrong ConfigKey and that's why it attempts to reconfigure).

The same config was working with SEB for macOS. If this can be confirmed, then the issue is definitely in SEB for Windows and not in Moodle.

from seb-win-refactoring.

The code related to the configuration key calculation hasn't changed in years: https://github.com/SafeExamBrowser/seb-win-refactoring/blame/master/SafeExamBrowser.Configuration/ConfigurationData/DataProcessor.cs#L44. If it is an issue, then it has been there since the beginning.

[...] we suspect an incompatibility between SEB 3.7 and Moodle 4.1.* when having some elements (apps in our case) in the SEB config file and letting Moodle calculate the key.

The problem should be on Moodle side, but knowing that it works in 3.5 and not in 3.7 we are not certain.

This would indicate an issue on Moodle side, otherwise it would neither work with version 3.5.x as the code hasn't changed for years (4 years to be exact, whereas SEB 3.5.0 has been released last year).

from seb-win-refactoring.

We got a similar issue.

I upload a config file to a moodle quiz, created with SEB 3.5., leaving the start url blank to use it with varius quizzes. It works fine, without entering the browser/exam key (till now I thought/think, that moodle alters the file, filling in the Start URL and recalculating the Keys).
SEBs not using this config get the error message that the Browser key could not be validated.

I updated to SEB 3.7, altered the exit password and saved the file -> Moodle displays that the key is not working.

I created a fresh new file, same error.

I switched back to SEB 3.5, opened the original SEB file and changed the password -> Uploaded to moodle -> the quiz starts as expected.

We are using Moodle 4.1

Best regards
Sebastian

from seb-win-refactoring.

Hi Sebastian,

Validation process for Browser keys in moodle:
is HTTP_X_SAFEEXAMBROWSER_REQUESTHASH (or JS API) sent via seb client equals to the sha256 hashing of the URL* + Actual valid key entered in quiz settings).. if not equal, then fail with an error.
URL: URL of the page on which the SEB JS API generated the keys. i.e usually at the quiz view page (/mod/quiz/view.php). <-- I have the feeling that the URL is the core reason for the failure of the validation. <-- for example: you leave the starturl empty, but moodle try to match the generated key in seb client against the quiz url then it fails (only if the keys are entered in the quiz, otherwise, it works fine)

If the use of modern browser is set in seb client, then the key is being sent from seb client via JS API (instead of headers). if you wish to debug further and help us find out why it doesnt work on your side, disable the usage of JS API (via unticking of use modern browser setting in seb client config) and try again -> this time its being sent via header instead of JS API.

if it still gives you an error, then dig further:

1. browser keys in moodle are validated on basis of what you have in the quiz settings (Browser keys, one per line) against what is being sent from seb client via a http header called (HTTP_X_SAFEEXAMBROWSER_REQUESTHASH). You should: 1. verify that the browser keys you entered in moodle are actually correctly generated. 2. make sure that custom headers are allowed in your web server (especially being forwarded and accepted if you are using a proxy), the header namely called HTTP_X_SAFEEXAMBROWSER_REQUESTHASH and also HTTP_X_SAFEEXAMBROWSER_CONFIGKEYHASH is required too.

2. Moodle does the validation if, and only if, you fill the browser keys in quiz settings.. may I suggest you read the browser keys documentation.

When you alter anything in the config, then you technically need also to regenerate the the config keys and the browser keys too, and then update them in moodle.

Ps Because you are using moodle 4.1 (the plugin, while changed structure-wise, fundamentally is the same since technically, however, it makes it harder for us to pin point precisely due to our usage of moodle 4.3).

from seb-win-refactoring.

Sometime ago someone reported a similar issue and in that case it was because of permittedProcesses in their SEB config (seems that some special characters, maybe backslash in the path of such allowed applications, cause SEB Windows to calculate a wrong ConfigKey and that's why it attempts to reconfigure).

The same config was working with SEB for macOS. If this can be confirmed, then the issue is definitely in SEB for Windows and not in Moodle.

IMPORTANT READ THIS IF YOU USE PERMITTED PROCESSES

in that case a bug in current versions of SEB for Windows is the reason for failing key. Try it with the Mac SEB version or remove permitted processes from your settings to confirm it.

AGAIN, FIRST TRY IF IT IS BECAUSE IF PERMITTED PROCESSES BEFORE LOSING TIME WITH OTHER TESTS!

from seb-win-refactoring.

If the use of modern browser is set in seb client, then the key is being sent from seb client via JS API (instead of headers). if you wish to debug further and help us find out why it doesnt work on your side, disable the usage of JS API (via unticking of use modern browser setting in seb client config) and try again -> this time its being sent via header instead of JS API.

Hi Nexterday, on what pane of the config tool can I find this setting? I do not see anything similar to that. I searched the documentation for "modern", "header" and "js api", did not find anything.

Best regards
Sebastian

from seb-win-refactoring.

Apologies, I mixed it with Seb for Mac.. for windows: settings key sendBrowserExamKey = true

Again, pls match the starturl in the config with an actual quiz url. Js api sends the keys at that page only, so it checks against current url, hence the likeliness of failure

Ps please read Dani’s comment in case this has anything to do with the browser keys. Dani says it might well be the reason, this saves time in testing.

from seb-win-refactoring.

Hi nexterday and Daniel,

-> prohibited processes: my configuration does not allow any third party apps and I also removed all prohibited processes -> no success

-> I also tried unticking "send browserExamKey", combined with entering the URL of the Quiz in the config -> no success.

--
From what the UI of moodle writes, it does key validation even with no keys entered in the quiz setting, but only if you upload a SEB file.

I have the feeling that the URL is the core reason for the failure of the validation. <-- for example: you leave the starturl empty, but moodle try to match the generated key in seb client against the quiz url then it fails (only if the keys are entered in the quiz, otherwise, it works fine)

When I leave the quiz URL empty, moodle alters the SEB file and fills in the URL of the Quiz where it is uploaded (the version of the config that can be downloaded by students). I used the same (version 3.5) old file on different quizzes, even on different moodle plattforms, it works fine. When I open this file with a config tool greater than 3.7 and save it again, Moodle claims that the key validation fails (no matter if I enter a browser key or not).

(The last paragraph may be a repetition of what I wrote, except that I checked the files that are actually downloaded to configure the SEB).

Thanks guys for answering on a sunday evening :D

from seb-win-refactoring.

Interesting. Btw sendexamkeys should be ticked (not unticked).

Ok, can you share the url of the quiz, along with the generated exam key in seb, so I can check if generation is right? sharing the seb config too is good.

from seb-win-refactoring.

I tried both ways, ticked and unticked.

What I suppose to send:
Old config that I upload / altered version from Moodle (working)

new config/altered version (not working)

I am going to mail it right now.

Best regards

from seb-win-refactoring.

please include the exam browser keys you entered in moodle (and actual url to that quiz including the domain etc). NO user/pass access pls

from seb-win-refactoring.

@nexterday These are new keys added in version 3.7.0 - that should however not be an issue, as the algorithm should be version agnostic (unless there is a bug in the algorithm on Windows side, which unfortunately appears to be the case).

from seb-win-refactoring.

@dbuechel please note that it might not necessarily be the hashing algo, but potentially the client component <-- any addition to the URI here (even if its simple ? or #) it renders the keys invalid. If you have made a change in that component, its worth to have a look at.

from seb-win-refactoring.

@nexterday Thanks for the hint, yes will do so, I currently also cannot explain the behavior.

from seb-win-refactoring.

Primarily thanks to @nexterday, it turns out that in Moodle, when calculating the configuration key they convert the new configuration values batteryChargeThresholdCritical and batteryChargeThresholdLow of PLIST type real introduced with version 3.7.0 as follows:

"batteryChargeThresholdCritical":0.10000000000000001,"batteryChargeThresholdLow":0.20000000000000001

Whereas SEB for Windows will convert the values the same way as they're actually represented in the raw XML data:

"batteryChargeThresholdCritical":0.1,"batteryChargeThresholdLow":0.2

So we have here a classic floating-point precision issue, which I reckon always existed but now manifested due to the two new configuration values.

@danschlet I could not find a particular point in the specification under https://safeexambrowser.org/developer/seb-config-key.html with respect to floating-point precision numbers of type real. How are you converting them in your code? In SEB for Windows, these are currently converted using NumberFormatInfo.InvariantInfo.

Again many thanks to @nexterday, without whom I'd still be turning my code upside down looking for an issue or bug...

from seb-win-refactoring.

Most likely, the issue has always existed. I thought there already were configuration keys of type real when adding the new keys for version 3.7.0, but checking our current default configuration, it appears that's not the case.

from seb-win-refactoring.

So we'll definitely first need to define how floating-point numbers ought to be represented for the configuration key generation and then see where the issue most easily can be fixed. IMHO, this is as already presumed above an issue in Moodle and should ideally be fixed there.

from seb-win-refactoring.

We just verified that SEB for macOS and Windows actually do calculate the same configuration key value when using the new settings with floating-point numbers, so this again indicates that the issue primarily is on Moodle side.

We'll today discuss and define the default format for (floating-point) numbers which must be used for the calculation and furthermore see, if and how we may resolve this situation assuming that correcting the mistake in Moodle would take long(er) or too long to be the only measure of action.

from seb-win-refactoring.

Thanks @dbuechel - the json encoding precision is defaulted to 14 digits (php, python, perl, go, java and many others), which means even if sorted for moodle, it would still not work for others (ie ilias, edx and co). The main reason for floating in precision is for precise calculations, not for value display --> usually when we display a text or number, we always format it, and we never just render it, hence we do not see the precision at all.

When we use the float only for display (no actual calculation) in json encoding, we either use (i.e double quote them) or we round them (via calculation). if we try to round (or default precesion to 1 or 2), then that means core code change must happen in moodle (plus approval etc), and the same applies to all other systems where seb talks to. I doubt this can happen overnight, hence the suggestion that if we can eliminate the potential problems from their source (ie seb not sending < real />, but < string /> or < array />, or yet funnier if you wish to precision them to the common standard: 14 digits and send keep them as

from seb-win-refactoring.

The main reason for floating in precision is for precise calculations, not for value display --> usually when we display a text or number, we always format it, and we never just render it, hence we do not see the precision at all.

Exactly, that's why we'll define the required formatting for the configuration key calculation - which then obviously will need to be applied by all LMS resp. web applications using the key. These should either way never use a default JSON conversion, as the calculation already does require a very particular format not produced by default JSON notation (see https://safeexambrowser.org/developer/seb-config-key.html).

if we try to round (or default precesion to 1 or 2), then that means core code change must happen in moodle (plus approval etc), and the same applies to all other systems where seb talks to. I doubt this can happen overnight

That is particularly the issue we'll also discuss. Strictly speaking, we already do define very particular rules for the data format required for the calculation, so in theory all systems using the configuration key must adapt it and also respond to changes or updates. But given that this most likely will take a lot of time, we'll see whether we can e.g. scale the values to an integer and then convert them again when reading the configuration in the clients. Though that clearly is a workaround, and the more workarounds we have in the code, the more issues will arise every time we need to make a change (and forget that there has been a workaround due to issue X in LMS Y...).

from seb-win-refactoring.

@abowman-unige Thanks for the hint, yes that is exactly the issue here. Then maybe we do not need a workaround after all, if the issue will be fixed in Moodle within a reasonable time frame...?

from seb-win-refactoring.

@dbuechel most likely you dont need to rework it for moodle - the ones who use 4.1 need to ask moodle for back-port or simply upgrade their moodle to be able to use 3.7+

Remaining is ilias and other lms’s to be notified that they have to fix their precision (and also maybe we make a prominent note to the new comers about it so we lower support overhead). Unless of course you would like to proactively find a safe solution that fits all and regardless of certain rules and conditions.

from seb-win-refactoring.

Can't people just change that setting serialize_precision in their setup.php to get back the previous (working correctly with SEB) behavior?

from seb-win-refactoring.

I doubt anyone can skip the rules and fast forward core code changes. The precision is over 5 years old, and even the change as per tracker is not thought off because it defeats the purpose and also doesnt account for many other json encodings in moodle.. it passes to integration because no one dared to look into its effect on a massive software with massive number of plugins.

On the otherhand, almost all languages deal with precision in similar fashion - so we fixed it for moodle for now, but how about other systems?

In float calculating 2.19 is actually equal to 2.1899087877 hence the idea of floating in a plist is cumbersome; its meant for calculation and not for presenting

from seb-win-refactoring.

Maybe I didn't understand the previous conversation about the issue (too many details). What is the essence?

I thought that it worked correctly with SEB's ConfigKey calculation previously and since some Moodle or PHP update it doesn't work anymore(?).

So previously the CK calculation code correctly mapped values like 0.1 or 0.2 to the JSON, and now it maps them to 0.10000000000000001 or 0.20000000000000001.

Is there no easy way to restore it to the behavior before when the mapping worked correctly?

I don't care much if it doesn't work correctly for other LMS/assessment system integrations. As @dbuechel mentioned, they have to make sure that their implementation matches SEB's implementation. I honestly don't give a fart if PHP thinks it has to map 0.1 to 0.10000000000000001 when Java (SEB Server), C# .NET on Windows, Obj-C/Swift on macOS/iOS does it correctly. Then the PHP guys should get their shit together first...

from seb-win-refactoring.

In 2017, php came up with the idea that floats should be defaults to precision of 14 digits and some function to 17 digits just to standardise like other scripting languages etc.

now since that time we never treated these floats as strings because its meant for mathematical calculations rather than being taken as if they are strings like the case of hashing.

why it worked with seb (until 3.5)? Because you never had real (float) keys in your plist, but then it got added (battery and co) and then calculation of json encoding assumed them as extra bytes anyway which ended up not matching the config keys generated by seb.

Now that we dont care about precision in our moodle (many would, especially with certain plugins where float precision is very important such as for math, chemistry physics and precise point drawing etc) - we simply can change the precision in core moodle (or at php level) and move on.. the question raised then: what happens with other lms’s (illias edx or whatever)? They have to do the same (or being told or supported etc) which causes an overhead on seb team.. what we shall do then? My inquiry was, what if the real key is converted to string or array or, or then its quoted and calculation would work on any system. Its just a wonder and not a request.. just to lower overhead due to number of systems connected/using seb.

ps java (in our case seb server) encode them on standard 14 digits precision too. Maybe @anhefti needs to truncate them or they wont work. Basically on at least 7 main languages, the precision of floats is 14 digits

from seb-win-refactoring.

I do understand this, although I wonder why it previously worked with floating point values like 1.0 (which I had since SEB 3 for macOS in my configs and I assume I uploaded such files to Moodle 4.1 before).

You're surely right that converting those floats to strings would be safer and would save time for other people implementing support for SEB, so I guess we will have to go that path. Looks like @anhefti will have issues with that, as he cannot just change value types for existing setting keys in SEB Server. I actually also can't do that on Mac. So I guess we will have to implement a conversion just when creating the JSON for Config Key, which is significant additional work.

I still don't understand though why a floating point value of 0.1 is rounded to 0.10000000000000001 by Moodle. Seems like a bug to me.

from seb-win-refactoring.

Its not a bug in php, its designed as a standard - almost all languages have 14 digits auto precision or else java too has a bug. Look at the comment above again (I also add the seb server case in Ps)

from seb-win-refactoring.

Here is what AHE is doing. He is basically treating floats as doubles (defines the type of real as a double; ie does sort of implicit casting) in order to remove the precision. Basically he suffers from precision too due to < real /> in plist..

from seb-win-refactoring.

See the "special case" code plus casting et al.

from seb-win-refactoring.

And here is it also converted to double in c# (seb win):

Basically precision is correct.. and we all try to convert for plist real.. problem is in real.

from seb-win-refactoring.

I don't even know the difference between real and double to be honest. The problem is, that Apple uses only for floating point numbers in plist. And I just converted it to JSON with standard system APIs. Looks like this doesn't work on other platforms.

But anyways, we have to solve the issue in SEB somehow, I agree with that now. We will see how to achieve that best.

from seb-win-refactoring.

I fully understand.

If you look for example here https://github.com/SafeExamBrowser/seb-mac/blob/634c8ff5d179b4ddd834b9b231159fc64c6d2efd/SEB/SEBViewController.m#L346

you see that the float def got truncated to 2 digits in the log printing which means even c has the 14 digits.. so maybe we all truncate in all LMS’s in similar fashion or seb changes these real values to strings, then json encode them with double quotes and then no one in lms side has to worry about it.

This is not a matter in my hands because I influence neither - I just wanted to give an opinion so ye make a better and informed decision

from seb-win-refactoring.

In SEB Server I deal with 14 digits precision with the FORMATTER in code:

private static final DecimalFormat FORMATTER = new DecimalFormat("0.##############");

Java basically knows:
float : 32-bit precision IEEE 754 floating point
double : 64-bit precision IEEE 754 floating point

The formatter used now cuts the original double value (from the database) to a 14 digits precision floating point number and cutting also away tailing '0' values.
SEB Server can adapt to other formatting of floating point values for XML or JSON output (since these are simply text files/format)
So if I have to adapt to another format I can do that by changing the FORMATTER above while values in DB still are double values. This would be possible without any migration or so, and would apply immediately to all generated and downloaded SEB Configs from SEB Server.

So if we need some change on this SEB Server formatting, just tell me and I can change it for the release.

from seb-win-refactoring.

I think this is something seb team should agree on. From moodle side, and now that its in integration phase, it becomes dangerous to play with precision because then moodle wont understand it again (we keep chasing our tails). Only safe move at the moment (if ever decided on by seb team) is that they avoid < real > at all costs and consider changing it to stringie type of key, then no one should/would worry about non compliance. Its only a suggestion and it doesnt even address any potential mess in the coding part at seb side, so please ignore it if its not possible

from seb-win-refactoring.

We had an internal meeting and decided the following:

1. The data type real is a valid and official data type of the underlying PLIST format used for SEB configurations. Its usage is thus correct and intended.
2. The representation of floating-point numbers of type real for the configuration key calculation is however currently missing in our official documentation, but appears to be implicitly working the same way on macOS, Windows as well as SEB Server. We'll thus agree upon a format internally, update the documentation and inform here as well as on our website respectively.
3. Floating-point numbers must henceforth be represented as specified when building the JSON for the calculation of the configuration key. This may require changes and adaptions in LMS or other web applications using the configuration key functionality.

from seb-win-refactoring.

And using only scaled integer values for floating point numbers again would cause more effort and defy logic/the purpose of using a strongly typed XML format.

from seb-win-refactoring.

The calculation of a CK is not a standard XML to JSON conversion. It's a custom algorithm which has to be performed following our specification. Unfortunately we missed to specify how to handle <real> values though when Deeper Integration was implemented. We will add this now to the specification and communicate accordingly, as suggested by @dbuechel.

from seb-win-refactoring.

Hi Dani
Natural and integers do not have precision hence it works when there is no fraction even when its defined as float.

the precision in moodle is not seb specific but moodle wide specific and even if moodle doesnt change it, sysadmins are able to change it via php env ini file (same applies to all scripting languages). Only issue there is that sysadmins (and others involved) should know that this is a prerequisite. Some ppl might complain because it might have an effect on their 3rd party plugins (I yet to see anyone who can visually recognise 0.0000001 difference though).

it occurred to me that not as it can be complex to change (according to Damian and you) but also many users might already have a config here and there that might stop working due to any changes in seb client.

I think a bold “do it as in documentation” note should suffice for non moodle users, or old moodle versions users. I hope this wont cause further inquiries or support tickets though (maybe a small note to current users of main lms systems to notify them of the necessity to do so, should help reduce surprises).. At the end of the day seb shall dictate the mechanism when an easy fix is not possible.

from seb-win-refactoring.

It's really not a question of precision from the view of the specification of SEB settings (and configuration files), but of identifiable value types. It only becomes an issue in the implementation of the ConfigKey check. It's up to the developer who's implementing this check to consider how to handle values in a reproducible way.

We could even change the specification of these floating point values to cover a much smaller precision. Until now none of the existing settings require a 14 or 17 digit precision, likely a two or three digit places/fractions precision would be sufficient (for example 1.75 or 1.125). Still don't think that rounding 0.1 to 0.1000001 makes any kind of sense, seems like really bad implementation to me).

from seb-win-refactoring.

I think too that precision is stupid and should only be explicitly requested (via extra param) but sometimes the guys behind interpreters (or feature requests) come up with a release based on a horse blinker view.

I get always precision via google apis, but I never knew if they had an effect because (in golang for example) 2.34 is equal to 2.39988888887 if the variable is defined as float). There must be a use case for it, but still doesnt justify defaulting precision to beyond initial value assignment. Maybe some day I’ll see or hear of a real life case where this precision made a difference.

there is no point of making a precision of less than “standard”.. 3 or 4 digits still wont make a difference. As per Damians outcome of the meeting, keep as is and others have to change accordingly

from seb-win-refactoring.

I think too that precision is stupid and should only be explicitly requested (via extra param) but sometimes the guys behind interpreters (or feature requests) come up with a release based on a horse blinker view.

I get always precision via google apis, but I never knew if they had an effect because (in golang for example) 2.34 is equal to 2.39988888887 if the variable is defined as float). There must be a use case for it, but still doesnt justify defaulting precision to beyond initial value assignment. Maybe some day I’ll see or hear of a real life case where this precision made a difference.

You're right that precision is an issue and I guess we were naive not to expect any rounding issues (which could happen with weird fractions any time when the values are read into high precision floating point values and converted back into strings in a JSON). It's just too late to change it in all SEB clients/server I think (unless we accept that old configuration files won't be fully compatible and may still cause issues down the line).

It probably would have been the easier solution to refrain from using floating point numbers and use multiplied integers. For new settings that's a choice we can take when specifying those settings. Although I don't see a natural specification
for example for a scaling factor (3, 2.5, 1, 0.5, 0.25, 0.125 etc.) which could be easily human readable without having to do calculations.

from seb-win-refactoring.

We'll update the specification as previously stated, but the cause of the issue was in Moodle and has just recently been resolved. Affected users may update to Moodle versions 4.3.6 or 4.4.2 as indicated in the issue: https://tracker.moodle.org/browse/MDL-82286.

from seb-win-refactoring.