Here’s what’s new in the Projectify project management app since the last update blog on 2024-04-08.

Security

Password validation applied when changing passwords as well

A past update added password validation for user sign ups. This password validation logic now also applies to existing users changing their current password. This is the pull request that introduces this change. To reiterate, the current validation criteria are:

• The password can’t resemble other personal information like the user’s email address
• The password must contain at least 8 characters
• The password can’t be a commonly used password
• The password can’t be entirely numeric

Please keep in mind that these criteria only raise the lowest standard for passwords. They don’t guarantee that a password is actually difficult to crack and safe from brute-forcing. At JWP Consulting, we recommend use a password manager and generating unique and random passwords for each log in account to stay safe.

Bug fixes

Navigation confirmation shown incorrectly when editing tasks

When creating or editing tasks, the Projectify frontend navigates back to a task’s project page, after it has saved everything correctly in the backend. I have recently added a confirmation dialog to task creation and update screens. This confirmation dialog asks the user to confirm whether they want to navigate away from a task and discard their changes.

This dialog also opens when the Projectify frontend successfully saves a task. Akin to: error, this operation has succeeded.

The confirmation logic wasn’t “aware” of why page navigation is happening. When the user wants to leave the page and discard their changes, they might trigger it. When the app successfully saves a task, it redirects the user back to the project page. This also triggers the page navigation.

The solution is to keep track of the form’s state and whether a user has pressed the Save button, or not. Based on this state, the Projectify frontend can now correctly decide whether to show the confirmation dialog, or not.

Preferred name validation

Preferred names ending on periods were falsely rejected. This affect preferred names such as Firstname Lastname Jr..

The purpose of the original preferred name filtering was to prevent arbitrary content injection. Before, a user could set a preferred name to be a web address or domain name. Some email clients liberally turned this into clickable URLs. This happened despite Projectify emails being plain-text only, and thus not containing any HTML.

A user could, for example, change their name to a malicious web address and send out team member invitation emails. These emails would contain clickable links that could lead a victim to click a link not belonging to the Projectify app. The origin of this problem lies beyond the realm of the Projectify app. Still, we do everything possible prevent content injections like these

Names ending on a period aren’t rendered as clickable URLs in email clients. Projectify doesn’t need to reject these. I have changed the regular expression validating preferred emails in pull request #509.

Input validation remains a challenge, even when using secure frameworks. Peripheral software, such as email clients, can exhibit surprising behavior, and it’s up to us software developers to stay on top of this.

Other bug fixes

Here are some miscellaneous bug fixes added over the last few weeks:

• The error page would not correctly distinguish between 404-like errors and other errors, such as page render errors. This pull request fixes this issue.

New features

Here are some small quality-of-life updates from the last few weeks:

• Svelte optimizes image asset using enhanced:img in this pull request. This makes pages lighter and faster to load.
• A sitemap is now rendered to ease crawling public facing pages.

Thank you

Thank you to all the kind people on the internet who have been trying out the Projectify app over the last few weeks and have reported so many issues.