Activity for John Beranek
-
John Beranek created a blog post
MRBS 1.11.5 released
-
MRBS 1.11.4 released
-
MRBS 1.11.4 releases
-
MRBS project support change
-
Cross-Site-Scripting (XSS)
-
This is now tracked at https://github.com/meeting-room-booking-system/mrbs-code/issues/744
-
MRBS 1.11.3 released
-
MRBS 1.11.2 released
-
OK, the containing directories are back too, for both zip and tar.gz.
-
mrbs tarballs on SF are tar, not tar.gz
-
Files gzipped and re-uploaded. Have also fixed the bug in the release script.
-
Oh wow, well spotted. That will be caused by a bug in my release script since MRBS moved to Git. I'll take a look.
-
MRBS 1.11.1 released
-
I'd go further and suggest that if you make changes to MRBS you'd be best off either: * Maintaining a fork of the repository, so you can merge future changes more easily. * Looking at whether you could structure your changes in a way that makes them generic enough to offer back to the project.
-
In either case, you're looking for https://github.com/meeting-room-booking-system/mrbs-code/fork
-
I'd go further and suggest that if you make changes to MRBS you'd be best off either: * Maintaining a fork of the repository, so you can merge future changes more easily. * Look at whether you could structure your changes in a way that makes them generic enough to offer back to the project.
-
(By the way, see the section "SAML Authentication" in MRBS's AUTHENTICATION instructions)
-
What this leaves is SimpleSAML to Azure AD which is...less than simple.
-
If the MRBS installation is being hosted outside of the school you'd need a way to do secure LDAP to authenticate against a school Active Directory server though. Not many people are willing to allow LDAP access to AD from outside their organisation...
-
TLS version will be based on your version of PHP/OS combination. I'd guess you're using either an old OS or version of PHP
-
I'm a bit confused by this multi-instance support. It's certainly non-standard MRBS code, and it would seem to be a lot easier to just have 4 copies of the MRBS code, each served by the web server.
-
It will do, or at least an email address verified in the account.
-
'access' is just a POSIX/Unix timestamp https://www.epochconverter.com/ https://en.wikipedia.org/wiki/Unix_time
-
'access' is just a POSIX/Unix timestamp https://www.epochconverter.com/
-
MRBS 1.11.0 released
-
Not sure if your config got corrupted getting into the ticket, but <directory "d:\mrbs\web"=""> is wrong, it should be: <directory "d:\mrbs\web">
-
Typically you can just do: <VirtualHost *:8081>
-
The context of my above question is that Active Directory does not have group objects which have "memberuid" properties, so this wouldn't work: $ldap_filter_base_dn = "OU=blank,OU=blank,OU=blank,OU=blank,DC=****,DC=local"; $ldap_filter_user_attr = "memberuid";
-
Looking at the documentation in systemdefaults.inc.php it says: // If you need to filter a user by the group a user is in with an LDAP // directory which stores group membership in the group object // (like OpenLDAP) then you need to search for the groups they are // in. If you want to do this, define the following two variables, an // an appropriate $ldap_filter. e.g.: // $ldap_filter_base_dn = "ou=Groups,dc=example,dc=com"; $ldap_filter_user_attr = "memberuid"; // $ldap_filter = "cn=MRBS Users";...
-
It's not made entirely clear in the documentation, but setting both $ldap_user_attrib and $ldap_dn_search_attrib doesn't really make sense. $ldap_dn_search_attrib turns on functionality for finding a user in the directory by performing an initial search in the directory. If $ldap_dn_search_attribute is not set, then MRBS will just build a user's DN, and then authenticate to the directory as that DN to check the credentials.
-
Ticket moved from /p/mrbs/bugs/526/
-
Hmm, moved the ticket but just noticed you're not logged in, so may not see it...I'll move it back...
-
Ticket moved from /p/mrbs/patches/114/
-
1.9.0 to 1.10.0 upgrade leads to error with PostgreSQL backend
-
1.9.9 to 1.10.0 upgrade leads to error with PostgreSQL backend
-
From systemdefaults.inc.php (add the config to config.inc.php): // If you don't want to use types then uncomment the following line. (The booking will // still have a type associated with it in the database, which will be the default type.) // unset($booking_types);
-
I can't remember the exact logic for setting the area's min/max deletion settings, shown here.
-
From config.inc.php: // Set this to true if you want to prevent users editing or deleting approved bookings. // Note that this setting only applies if booking approval is in force for the area. // If it isn't in force you can prevent bookings being edited or deleted by using the // min and max delete ahead settings. $approved_bookings_cannot_be_changed = false;
-
From config.inc.php: // Set this to true if you want to prevent users editing or deleting approved bookings. // Note that this setting only applies if booking approval is in force for the area. // If it isn't in force you can prevent bookings being edited or deleted by using the // min and max delete ahead settings. $approved_bookings_cannot_be_changed = false;
-
I think tools like phpMyAdmin will do things like this too.
-
You may mean: $auth['deny_public_access'] = true;
-
It looks to me like that "No such file or directory" is coming from your MySQL server, have you specified the correct database/table prefix options?
-
It looks to me like that "No such file or directory" is coming from your MySQL server, have you specific the correct database/table prefix options?
-
It looks to me like that "No such file or directory" is coming from your MySQL server, have your specific the correct database/table prefix options?
-
Very confusing indeed, allow_registration was only added to the table mrbs_entry at DB schema version 67, and the table mrbs_sessions was only added at DB schema 56.
-
Well, I'd remark you're using a version of MRBS which was released 4 years before the PHP 7.4 version you're using. I'd therefore not be surprised if MRBS 1.5.0 doesn't work on PHP 7.4.
-
Or, if the SMTP server has an SSL certificate of mail.domain.com instead of smtp.domain.com, then use mail.domain.com in MRBS config (if the DNS for that goes to the expected place)
-
I believe this suggests you've not managed to upload all of MRBS's files, potentially CSS files. Either they're not on the server, or aren't being served correctly. Look in the browser console/DevTools for files which have failed to load.
-
These website hosting issues aren't really something MRBS developers can assist with - there are too many various ways to host PHP sites which means that we can't really support this.
-
MRBS 1.10.0 released
-
Demo site not working
-
This is now fixed, it seems having 1500 areas configured takes the site's RAM usage beyond Sourceforge's web hosting limits.
-
Something weird going on with Sourceforge hosting there - a workaround for now would be to use the other demo site: https://mrbs.sourceforge.io/periodsmrbs/
-
A good source for an updated bundle of root certificates https://curl.se/docs/caextract.html
-
It should be possible to update the CA certificates in your hosting environment even without an OS upgrade. If you're using a hosting company they should really be up to this.
-
Was thinking this is just a typo in config.inc.php for $url_base ?
-
This little bit of debug from the original report is the telling bit that shows the "wrong" sort of LDAP search behaviour was being used on the 1.9.4 installation, namely the "constructed dn": constructed dn 'uid=sagordon,ou=people,dc=uvic,dc=ca'
-
Indeed, which is why I've been sat here comparing the code in 1.7.1 and 'main' - I still don't see it. Baffled.
-
So, for as long as I can remember, $ldap_user_attrib and $ldap_dn_search_attrib have been mutually exclusive, as they change the way LDAP authentication works so much. I say this as the person who wrote much of the extra LDAP code a fair number of years ago. What was never made clear enough I believe was the documentation - I went back to the text in systemdefaults.inc.php from 1.7.1, and it's certainly not clear then: https://github.com/meeting-room-booking-system/mrbs-code/blob/mrbs-1_7_1/web/systemdefaults.inc.php#L763...
-
So, for as long as I can remember, $ldap_user_attrib and $ldap_dn_search_attrib have been mutually exclusive, as they change the way LDAP authentication works so much. I say this as the person who wrote much of the extra LDAP code a fair number of years ago. What was never made clear enough I believe was the documentation - I went back to the text in systemdefaults.inc.php from 1.7.1, and it's certainly not clear then: https://github.com/meeting-room-booking-system/mrbs-code/blob/mrbs-1_7_1/web/systemdefaults.inc.php#L763...
-
I won't drone on too much more, but it's worth saying that what I've said above about MRBS 1.7.1 also goes for MRBS 1.9.4.
-
So, for as long as I can remember, $ldap_user_attrib and $ldap_dn_search_attrib have been mutually exclusive, as they change the way LDAP authentication works so much. I say this as the person who wrote much of the extra LDAP code a fair number of years ago. What was never made clear enough I believe was the documentation - I went back to the text in systemdefaults.inc.php from 1.7.1, and it's certainly not clear then: https://github.com/meeting-room-booking-system/mrbs-code/blob/mrbs-1_7_1/web/systemdefaults.inc.php#L763...
-
So, for as long as I can remember, $ldap_user_attrib and $ldap_dn_search_attrib have been mutually exclusive, as they change the way LDAP authentication works so much. I say this as the person who wrote much of the extra LDAP code a fair number of years ago. What was never made clear enough I believe was the documentation - I went back to the text in systemdefaults.inc.php from 1.7.1, and it's certainly not clear then: https://github.com/meeting-room-booking-system/mrbs-code/blob/mrbs-1_7_1/web/systemdefaults.inc.php#L763...
-
However, I must say that an LDAP URL of ldaps://whatever:389 looks a little odd, as that's instructing the LDAP client to do explicit TLS, which is not normally what servers do on port 389, which is implicit/STARTTLS. However, I'm not sure we handle the URL any differently been the 2 MRBS versions
-
If I had to have a guess, I'd guess the new system is somehow not trusting the TLS certificate of the LDAP server, though that does seem less likely if the 2 systems are on the same server. Do they both use the same PHP?
-
You just need to edit the area, see screenshot.
-
Corresponding screenshot from current MRBS.
-
Shortcut URL being https://github.com/meeting-room-booking-system/mrbs-code/archive/refs/heads/main.zip
-
It still sounds like your installation is somehow corrupt. Have you tried moving your existing installation somewhere else, unpacking the updated build in a clean directory, and then copying in your config and any custom config (themes, CSS, images)?
-
That sounds rather like you've not managed to unpack the whole of the 'main' release into your installation. 'registrant_limit_enabled' is now a standard field, and the installation would know that if it was complete.
-
You're very much correct, I created https://github.com/meeting-room-booking-system/mrbs-code/issues/15
-
If you're trying to use an external session you likely want to be writing a Session class, not an Auth class.
-
MRBS 1.9.4 released
-
Perhaps change that section of defaultincludes.inc to: if (!empty($_ENV['MRBS_ROOT'])) { define('MRBS_ROOT', $_ENV['MRBS_ROOT']); } else { define('MRBS_ROOT', __DIR__); // Root of MRBS installation }
-
Perhaps change that section of defaultincludes.php to: if (!empty($_ENV['MRBS_ROOT'])) { define('MRBS_ROOT', $_ENV['MRBS_ROOT']); } else { define('MRBS_ROOT', __DIR__); // Root of MRBS installation }
-
$ldap_dn_search_dn = "cn=*,cn=users,dc=company,dc=com"; Was this just you obscuring personal details, as it doesn't look like a valid DN to me... That field is the LDAP Distinguished Name to login as, so for a Active Directory system perhaps: cn=queryuser,ou=users,dc=example,dc=com
-
MRBS 1.9.3 released
-
It will be in your PHP error log, which would either be somewhere like your web server error log, or your php-fpm log.
-
1) LDAP with TLS but using an IP address seems unlikely to work, given that the certificate would need to match 2) "$ldap_debug = true;" in config.inc.php
-
Oh, I guess I was wrong when I presumed you didn't have a MacOS system Campbell - only me that's anti-Mac then ;)
-
https://stackoverflow.com/questions/21182375/php-setlocale-on-osx-freebsd-doesnt-work ?
-
From my brief research it seems the locale would need to be: de_DE.UTF-8 (on Linux both de_DE.utf8, de_DE.UTF8 and de_DE.UTF-8 work)
-
From my brief research it seems the locale would need to be: de_DE.UTF-8
-
What is the output of this command from a console window? locale -a | grep -i de
-
Oh wait, XAMPP on MacOS is it? I didn't know XAMPP existed for anything but Windows None of the developers have a MacOS machine, so wouldn't have been able to test behaviour
-
Oh wait, XAMPP on MacOS is it? I didn't know XAMPP existed for anyone but Windows None of the developers have a MacOS machine, so wouldn't have been able to test behaviour
-
Oh wait, XAMPP on MacOS is it?
-
Of note is that the Javascript date picker seems to be using a German format, so it must just be the server side dates, and server is on Windows...
-
Upgrade to 1.9.2 session has expired
1 >