Filed Under: Development by midas — Comments Off on Selectively process multiple booking requests
August 5, 2024
One of the helpful features of MIDAS is the ability to allow visitors to your website to check availability of your facilities and submit booking “requests” online. They can do this without logging in or requiring an account.
Once a booking request is submitted, the manager(s) of the request facility are notified. A manager can then then quickly approve or reject the booking request in MIDAS with just a few clicks.
This saved time in instances where there were numerous booking requests which all required approval or rejection.
To be able to bulk approve a number of booking requests, a setting was made available. This instructed MIDAS as to the order in which it should approve requests when approving them in bulk.
The “Bulk Approval Order” setting has the following options:
Earliest Requested First – Booking requests will be approved in the order in which they were received. The earliest request received will be approved first.
Latest Requested First – Booking requests will be approved in the reverse order in which they were received. The most recently received request will be approved first.
Earliest Commencing First – Booking requests will be approved in the order in which the requested booking would start. Requests for the soonest start times will be approved first.
Latest Commencing First – Booking requests will be approved in the reverse order in which the requested booking would start. Requests for the furthest away start times will be approved first.
For MIDAS v4.37 we’re giving managers even greater control when it comes to processing multiple booking requests.
In addition to be able to approve or reject one booking request at a time, or “bulk” approve/reject ALL requests at the same time, you can now also selectively approve/reject multiple requests.
On the Pending Booking Requests screen there’s now a checkbox alongside each request that’s awaiting processing.
A manager can use these tick boxes to select multiple requests and then click the “Approve Selected” or “Reject Selected” buttons at the bottom of the screen to process the selected requests accordingly.
If no requests are selected, the “Approve Selected” and “Reject Selected” buttons change. They then become the familiar “Approve All” and “Reject All” options which if used process all requests in the queue.
Filed Under: Development by midas — Comments Off on Custom Field Improvements in v4.37
July 31, 2024
MIDAS includes a number of useful booking and client fields out-of-the-box. You can use these to capture information about your clients and their bookings. In addition, the software also allows you to create custom fields to record additional information with each booking or client.
For MIDAS v4.37, we’re making improvements to a couple of the ‘custom’ fields you can add to your scheduling system.
Custom “Text Area” fields can have a height set and can be resizable
Sometimes a single-line input field may not be sufficient to capture the amount of information you desire. In such instances, MIDAS allows you to alternatively create a multi-line “Text Area” input field.
Until now, creating a custom Text Area field would display a text input field with a relatively small height. Whilst its contents would be scrollable, the field would typically only show 2-3 lines of text at a time.
Now when creating (or editing) a custom Text Area field, you’ll have more control! You’ll be able to specify the number of rows that should be displayed at any given time on the field.
So if you anticipate that your custom field is only going to hold a couple of lines of text, you can set the number of rows to display low. But, if you expect your custom field to capture dozens of lines of text, you can increase the number of rows shown.
Furthermore, you can also set a custom Text Area field to be “Resizable”. When a Text Area field is set as resizable, a user will be able to drag the bottom of the custom Text Area field down to allow the display of more lines of text at once.
Custom file uploads can be set to either view or save/download the file when clicked
When we implemented this custom field type in 2014, we configured MIDAS to ‘hint’ to an end-users user’s browser that an uploaded and attached file should be ‘downloaded’ to the user’s device when clicked.
In those days, it wasn’t common place for web browsers to be able to open a variety of file types. There was even a time when browsers would struggle to open and correctly display PDF files.
These days, web browsers can open and display a wide range of document/file types.
For v4.37, we’ve provided administrators with the option to allow MIDAS to ‘hint’ to user’s browsers whether an custom file upload should be either ‘downloaded’ to the user’s device when clicked, or ‘opened/displayed’ in a new window/tab instead.
So if you’re attaching PDF files to bookings, for instance, you can now instruct browsers to display these files in your browser instead of prompting you to download them to your device.
Please note that MIDAS only provides ‘hints’ to user’s browsers as to whether to view or download an attached file. It’s down to individual browsers as to whether they respect these hints and how they process the attached files.
Filed Under: Development by midas — Comments Off on Deprecating some outdated settings
July 25, 2024
In MIDAS v4.37, we’re deprecating some outdated privacy and security settings.
In this post, we’ll outline what’s changing and explain the reasons behind the decision to remove these options.
“SSL Access” setting has been removed
In the early days of the World Wide Web, you connected to websites over “http”.
“http” connections were not secure and could be intercepted. So along came “https”, which allowed visitors to connect to websites over encrypted Secure Socket Layer – or SSL – connections.
However, adoption of “https” was initially slow by the majority of the World Wide Web. Primarily, this was due to SSL certificates being very expensive. Large financial institutions were naturally quick to jump on https. However, the price of SSL certificates put securing websites with https out of reach of the average webmaster. Especially when the cost to renew them every 1-2 years was factored in.
Now, as you may know, we’ve been developing our web based MIDAS room booking software for nearly 20 years now! When we first began to offer a “cloud hosted” booking system to customers (way back in 2007), SSL/https use around the web was not wide spread, and was expensive to implement.
Initially in 2007, we offered our cloud-hosted customers the option of being able to access their hosted MIDAS system over secure https. This was available via an optional (paid) addon for their scheduling system.
As part of this, we added a new “SSL Access” setting to v3.13. This allowed administrators to control whether insecure http and/or secure https connections would be permitted to their MIDAS system.
In August 2012, we then took the further decision to include an SSL Certificate to enable secure connections for all our existing and future cloud hosted customers. At the same time, we enforced https connections to all hosted MIDAS system.
Consequently, the “SSL Access” option first introduced in MIDAS v3.13 became redundant for our cloud-hosted customers. Since 2015 and MIDAS v4.09, this option has no longer been available in cloud-hosted editions of our booking system.
In the following years, gradually the cost of SSL certificates reduced. Then in 2016, along came a game-changing service called “Let’s Encrypt“. Let’s Encrypt offered FREE SSL certificates for all. This finally allowed every webmaster the ability to “secure” visitor connections to their websites at zero cost.
Now, in 2024, SSL/https certificates are the norm – in fact, all modern web browsers now alert you if you attempt to visit an insecure website via http.
So whilst we removed the “SSL Access” settings in cloud-hosted MIDAS systems back in 2015, we’re now also removing these settings for self-hosted customers starting with MIDAS v4.37.
“Allowed IP Range” setting has been removed (self hosted editions only)
The “Allowed IP Range” setting is one of the earliest security settings we provided in our room booking system. In fact, it was first introduced in v1.35 back in August 2007.
The setting allows an administrator to restrict access to their MIDAS system to an IP address or range.
This can be useful if a MIDAS system is hosted on a public-facing web server, which potentially could be accessed by anyone worldwide. The “Allowed IP Range” setting can be used to restrict access to users in your own country, organization, or to just you!
However, one of the limitations of this setting is that it only supports ipv4 address, and not ipv6 addresses.
Also, in the years since this setting was first introduced, other security and firewall products are available which provide greater control over access to websites, apps, and servers.
Therefore, starting with MIDAS v4.37, we have removed the “Allowed IP Range” setting in self-hosted editions.
If you’re a self-hosted customer and wish to restrict access to your MIDAS system by IP address you should consider other options to achieve this.
For instance, on Apache servers, you can easily allow/deny access by ip address/range in your httpd.conf or .htaccess files. For more information, please see Apache’s guidance on access control.
“Do Not Track (dnt)” has been superseded by “Global Privacy Control”
“Do Not Track” – or ‘dnt’ for short – was an official HTTP header first proposed in 2009. It was intended to allow user to opt-out of tracking by websites.
By 2011, all major web browsers had implemented support for the proposed “Do Not Track” features.
In 2017, with the release of MIDAS v4.16, we included an “Honor user’s Do Not Track preference” setting.
If enabled (and if an end-user had also enabled the “Do Not Track” feature in their browser), MIDAS would not log the user’s IP address in the Recent Activity Log.
However, globally, recognition and support of the “Do Not Track” HTTP header by websites was poor. So much so that in January 2019, the “Do No Track” HTTP header was officially deprecated. A month later, Apple removed DNT support from their Safari browser.
Whilst some other browsers still continue to offer a “Do Not Track” setting, it has since been supersede by a new “Global Privacy Control” – or GPC – header.
At time of writing, Global Privacy Control is still classed as an “experimental” and “non standard” technology, and it’s behaviour may change in the future.
But for MIDAS v4.37, we’ll support both DNT and GPC features. The “Honor user’s Do Not Track preference” setting will be renamed to “Honor user’s privacy preferences” to reflect this.
It’s likely that in a future update we’ll fully drop support the deprecated “DNT” header. At time of writing though, as some browsers still support it, we’ll continue to support it too.
Filed Under: Development by midas — Comments Off on Improved Device Detection
April 24, 2024
Whenever your user account is logged into from a new or unfamiliar device, MIDAS can automatically alert you by email. This additional security feature helps keep your account secure by alerting you to suspicious logins. An unfamiliar login notification includes details of the browser, operating system, IP address, and – with our optional Geolocation addon – location, of the device that’s just logged into your account.
Until now, MIDAS has been unable to distinguish between more recent operating system versions. For example, between Windows 10 and Windows 11, or between MacOS Ventura and Sonoma.
This is because MIDAS has relied on the “User Agent” (UA) string that’s presented by the browser that’s logging in.
Here’s an example of a browser’s “User Agent” string presented to a web server:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
There’s a lot of information there, but essentially, from this string MIDAS can derive that it’s a Windows (64 bit) device, and the browser is Google Chrome 123.
Here’s another example:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:124.0) Gecko/20100101 Firefox/124.0
From this, MIDAS can derive that it’s a macOS device, and the browser is Firefox 124.
But wait… can’t MIDAS also determine the exact version of the operating system from these UA strings?
Mac OS X 10.15…. Catalina? …Big Sur? …Monterey? …Ventura?
Doesn’t “Mac OS X 10.15” imply macOS Catalina? ..and doesn’t “Windows NT 10.0” imply Windows 10?
Well, that used to be the case, but not any more!
Modern browsers now “clamp” the versions of more recent macOS/Windows operating systems reported by the User Agent string. For macOS operating systems, the User Agent string will report a maximum of macOS X 10.15. For Windows operating systems, a maximum of Windows 10 will be reported. Browsers no longer natively report the specific version of the operating system they’re running on.
This means that a Chrome browser running on either Windows 10 or Windows 11 will report “Windows NT 10.0”. Similarly, macOS Catalina (10.15), Big Sur (11), Monterey (12), Ventura (13), and Sonoma (14), will all report “Mac OS X 10.15”.
So Windows 10 and 11 are the same then?
In an effort to improve user privacy, browsers have decided to no longer reveal the specific operating system version a user is using when visiting a website, in order to make it harder for websites to “fingerprint” users.
“Fingerprinting” is a technique that some websites employ to uniquely identify and potentially track visitors.
So because of these changes to the way browsers report User Agent strings, it’s been difficult for MIDAS to provide a unfamiliar login notification containing details of exact operating system version that’s been used to login to an account.
But advancements in technology mean that we’ve now been able to make improvements to device detection for MIDAS v4.36.
Utilizing New “Client Hint” technology
Client hints are a set of HTTP request headers that provide useful information about the client such as device type and network conditions. This then allow servers to optimize what is served for those conditions.
Unlike the traditional “User Agent String”, client hints provide a more efficient and privacy preserving way of getting the desired information.
A web server can proactively request the client hint headers they are interested in. The browser can then include the requested headers in subsequent requests.
If the web server upon which a MIDAS system is running proactively requests either the “sec-ch-ua-platform-version” or “ua-platform-version” client hint header, MIDAS can receive details of the user’s operating system version.
Unfamiliar login notifications (if enabled) can then provide much more accurate information as to the operating system of the new device which has logged into your account.
Web Server Configuration
Because a web server has to proactively request these new client headers in order for browsers to respond to them, servers have to be configured accordingly.
All of our cloud-hosted nodes have been appropriately configured. Our client servers now proactively request the necessary Client Hint headers. This in turn means that all cloud hosted users can start to take advantage of these improvements to device detection and unfamiliar login notifications.
For self-hosted customers, a small configuration change to the web server when your MIDAS system is running from is required.