f44d88e134 feat(password): email-confirmed password setup for SSO accounts (#10649)
* feat(password): add email-confirmed password setup for SSO accounts

SSO-only accounts (Google, GitHub, OIDC) now have a secure path to add
a password credential without requiring direct session trust.

**Problem:** Previously, password setup for SSO users either required an
existing password (blocking SSO-only users entirely) or would have needed
to trust the session token alone to create a persistent credential — a
security gap where a compromised session could silently add a password.

**Solution:** Email-confirmed flow that reuses the existing recovery
infrastructure:

1. `checkHasPassword` RPC — authenticates via session token, returns
   whether the account has a password hash set (drives UI branching).
2. `requestPasswordSetup` RPC — authenticates via session token, looks up
   the account's verified email social ID, generates a recovery token
   (`restoreEmail` claim), and sends a "Password recovery" email via the
   existing mail service. No DB schema changes.
3. `PasswordRestore.svelte` (unchanged) handles the link click → calls
   the existing `restorePassword` RPC → password is set.

**UI changes** (`Password.svelte`):
- `hasPassword === false` → "Set a password" panel with description and
  "Send setup link" button
- On success → "Check your email for a link to set your password."
- On `SocialIdNotFound` → "No email address is linked to your account."
  with guidance to add one via Account Settings → Manage Identities
- `hasPassword === true` → existing "Change password" form (unchanged)

**Account client:** Added `checkHasPassword()` and
`requestPasswordSetup()` methods to `AccountClientImpl`; both registered
as platform resource functions (`login.function.CheckHasPassword` /
`login.function.RequestPasswordSetup`).

Signed-off-by: Don Kendall <dkendall@ledoweb.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Don Kendall <kendall@donkendall.com>

* test(password): add unit tests for SSO password setup RPCs

ssoPassword.test.ts — 12 tests covering:
- checkHasPassword: returns true/false for hash+salt presence, false for
  partial state (hash-only or salt-only), error for missing account
- changePassword: rejects empty old/new passwords, rejects wrong
  oldPassword (hash mismatch)
- requestPasswordSetup: sends email when email social ID exists, returns
  SocialIdNotFound when no email is linked, handles mail service failures
  gracefully (logs error, does not rethrow)

signupTokenGuard.test.ts — added edge-case for empty-string token to
document current guard behaviour (token != null passes empty string
through; noted as a future hardening opportunity).

Signed-off-by: Don Kendall <dkendall@ledoweb.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Don Kendall <kendall@donkendall.com>

* chore(dev): add dev-local webpack proxy for local Docker compose stack

Adds a `dev-local` CLIENT_TYPE that proxies webpack dev server requests
to a local Docker compose stack (nginx at localhost:8088), following the
same pattern as the existing `dev-server`, `dev-huly`, etc. modes.

Useful for developing frontend changes against a fully running local
backend without needing `huly.local` DNS configuration.

Signed-off-by: Don Kendall <dkendall@ledoweb.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Don Kendall <kendall@donkendall.com>

* feat(email): redesign transactional emails with proper HTML and dedicated password setup template

All account service email templates were bare <p> tags with no styling,
branding, or call-to-action buttons. Replaced with production-quality
HTML emails using email-safe table layout and inline CSS.

Design: Huly wordmark on dark (#18181B) header, white card body, dark
CTA button, subtle border, system font stack. Plain-text versions
updated to match for clients that prefer text.

Templates improved:
- RecoveryHTML/Text — password reset flow
- ConfirmationHTML/Text — email verification on signup
- InviteHTML/Text — workspace invitation
- ResendInviteHTML/Text — re-invitation
- OtpHTML/Text — sign-in code with large monospace code display

New dedicated template for SSO password setup (PasswordSetupHTML/Text/
Subject) so the setup email has copy distinct from forgot-password
recovery. requestPasswordSetup now uses these instead of RecoveryHTML.
Subject: "Set a password for your Huly account".

Other language files updated with the new PasswordSetup* keys
(English copy as fallback — translations can follow separately).

Signed-off-by: Don Kendall <dkendall@ledoweb.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Don Kendall <kendall@donkendall.com>

* fix(password): guard requestPasswordSetup against accounts with existing password

Add server-side check that rejects requestPasswordSetup calls from accounts
that already have a password hash+salt. The setup flow bypasses the
old-password requirement in changePassword, so it must be restricted to
SSO-only accounts. The UI already guards this branch but defence-in-depth
requires the server to enforce it independently.

Also adds JSDoc to requestPasswordSetup and extends unit test coverage:
- TokenError path for checkHasPassword (invalid/expired token)
- BadRequest guard for requestPasswordSetup on password-bearing accounts

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Don Kendall <kendall@donkendall.com>

* fix: add missing locale keys and fix eslint/formatting for CI

- Add 5 missing SSO password translation keys to all non-en locale files
  (SetPassword, SSOPasswordDescription, SendSetupLink, SSOPasswordEmailSent,
  SSONoEmailLinked) to fix locale parity test
- Replace non-null assertions with type casts in ssoPassword.test.ts
  to fix @typescript-eslint/no-non-null-assertion errors
- Revert unrelated tracker/github cosmetic changes that triggered
  pre-existing eslint errors in those packages

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Don Kendall <kendall@donkendall.com>

* fix: address review — remove dev/prod changes, translate PasswordSetup strings

- Revert dev/prod/webpack.config.js and package.json (per BykhovDenis)
- Translate PasswordSetupText and PasswordSetupSubject for all 10 locales
  (cs, de, es, fr, it, pt-br, pt, ru, tr, zh)
- PasswordSetupHTML stays in English (reviewer approved)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Don Kendall <kendall@donkendall.com>

---------

Signed-off-by: Don Kendall <dkendall@ledoweb.com>
Signed-off-by: Don Kendall <kendall@donkendall.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-21 03:53:18 +05:00
2026-03-06 22:17:46 +07:00
2026-03-06 22:17:46 +07:00
2025-12-18 00:40:41 +05:00
2025-11-26 19:15:30 +05:00
2026-02-25 15:20:46 +05:00
2025-10-15 11:51:48 +07:00
2025-10-07 20:23:46 +05:00
2025-01-14 12:12:15 +07:00
2026-03-02 21:46:02 +07:00
2026-01-10 15:23:38 +05:00
2021-08-02 21:39:24 +02:00
2026-01-29 14:44:13 +07:00

Huly Platform

X (formerly Twitter) Follow GitHub License

⭐️ Your star shines on us. Star us on GitHub!

About

The Huly Platform is a robust framework designed to accelerate the development of business applications, such as CRM systems. This repository includes several applications, such as Chat, Project Management, CRM, HRM, and ATS. Various teams are building products on top of the Platform, including Huly and TraceX.

Huly

Self-Hosting

If you're primarily interested in self-hosting Huly without the intention to modify or contribute to its development, please use huly-selfhost. This project offers a convenient method to host Huly using docker, designed for ease of use and quick setup. Explore this option to effortlessly enjoy Huly on your own server.

Activity

Alt

API Client

If you want to interact with Huly programmatically, check out our API Client documentation. The API client provides a typed interface for all Huly operations and can be used to build integrations and custom applications.

You can find API usage examples in the Huly examples repository.

Changelog

For detailed information about changes, improvements, and bug fixes in each version, see our Changelog.

Versions

The Huly Platform uses two types of version tags to distinguish between production-ready and development releases:

  • Production Versions (v*) - Stable releases for end users

    • Example: v0.7.310, v0.7.307, v0.6.501
    • These versions are recommended for production deployments
    • Suitable for self-hosted installations
    • Published with release notes on GitHub Releases
  • Development Versions (s*) - Pre-release builds for developers

    • Example: s0.7.313, s0.7.292, s0.7.288
    • Used for development and testing purposes
    • May contain experimental features or bug fixes
    • Not recommended for production use

Architecture

For detailed information about the platform architecture, services, and their interactions, see our Architecture Overview.

Table of Contents

Pre-requisites

Verification

To verify the installation, perform the following checks in your terminal:

  • Ensure that the docker commands are available:
docker --version
docker compose version

Branches & Contributing

  • The main branch is the default branch used for production deployments. Changes to this branch are made from the staging branch once a version is ready for community use.

  • The staging branch is used for pre-release testing. It is stable enough for testing but not yet ready for production deployment.

  • The develop branch is used for development and is the default branch for contributions.

We periodically merge develop into staging to perform testing builds. Once we are satisfied with the build quality in our pre-release deployment, we merge changes into main and release a new version to the community.

Setup dev environment

To initialise the communication submodule

git submodule init
git submodule update

To update the communication submodule

git submodule update

Authentication

This project uses GitHub Packages for dependency management. To successfully download dependencies, you need to generate a GitHub personal access token and log in to npm using that token.

Follow these steps:

  1. Generate a GitHub Token:
  • Log in to your GitHub account
  • Go to Settings > Developer settings > Personal access tokens (https://github.com/settings/personal-access-tokens)
  • Click Generate new token
  • Select the required scopes (at least read:packages)
  • Generate the token and copy it
  1. Authenticate with npm:
npm login --registry=https://npm.pkg.github.com

When prompted, enter your GitHub username, use the generated token as your password

Fast start

sh ./scripts/fast-start.sh

Installation

You need Microsoft's rush to install the application.

  1. Install Rush globally using the command:
npm install -g @microsoft/rush
  1. Navigate to the repository root and run the following commands:
rush install
rush build

Alternatively, you can just execute:

sh ./scripts/presetup-rush.sh

Build and run

Development environment setup requires Docker to be installed on system.

Support is available for both amd64 and arm64 containers on Linux and macOS.

cd ./dev/
rush build    # Will build all the required packages.
# rush rebuild  # could be used to omit build cache.
rush bundle   # Will prepare bundles.
rush package  # Will build all webpack packages.
rush validate # Will validate all sources with typescript and generate d.ts files required for ts-node execution.
rush svelte-check # Optional. svelte files validation using svelte-check.
rush docker:build   # Will build Docker containers for all applications in the local Docker environment.
rush docker:up # Will set up all the containers

Be aware rush docker:build will automatically execute all required phases like build, bundle, package.

Note: For resource-constrained machines, you can use the minified variants rush docker:min and rush docker:up:min to build and run only the required services (excludes hulypulse, redis, process, backup, rating, preview, link-preview, elastic, fulltext, payment, stats, print, sign, hulygun, hulykvs).

Alternatively, you can just execute:

sh ./scripts/build.sh

By default, Docker volumes named dev_db, dev_elastic, and dev_files will be created for the MongoDB, Elasticsearch, and MinIO instances.

Add the following lines to your hosts file:

  • macOS / Linux: /etc/hosts
  • Windows: C:\Windows\System32\drivers\etc\hosts
127.0.0.1 huly.local
::1 huly.local

Accessing the URL http://huly.local:8087 will lead you to the app in development mode.

Limitations:

  • Local installation does not support sending emails, thus disabling functionalities such as password recovery and email notifications.

Run in development mode

Development mode allows for live reloading and a smoother development process.

cd dev/prod
rush validate
rushx dev-server

Then go to http://localhost:8080

Select "Sign up" on the right panel and click the "Sign up with password" link at the bottom. Enter the new user's credentials, then proceed to create a workspace for them.

Update project structure and database

If the project's structure is updated, it may be necessary to relink and rebuild the projects.

rush update
rush build

Troubleshooting

If a build fails, but the code is correct, try to delete the build cache and retry.

# from the project root
rm -rf common/temp/build-cache

Build & Watch

For development purpose rush build:watch action could be used.

It includes build and validate phases in watch mode.

Tests

Unit tests

rush test # To execute all tests

rushx test # For individual test execution inside a package directory

UI tests

cd ./tests
rush build
rush bundle
rush docker:build
## creates test Docker containers and sets up test database
./prepare.sh
## runs UI tests
rushx uitest

To execute tests in the development environment, please follow these steps:

cd ./tests
./create-local.sh ## use ./restore-local.sh if you only want to restore the workspace to a predefined initial state for sanity.
cd ./sanity
rushx dev-uitest # To execute all tests against the development environment.
rushx dev-debug -g 'pattern' # To execute tests in debug mode with only the matching test pattern.

Package publishing

node ./common/scripts/bump.js -p projectName

Additional testing

This project is tested with BrowserStack.

WSL build guide

This guide describes the nuances of building and running the application from source code located on your NTFS drive, which is accessible from both Windows and WSL.

Prerequisites

Disk Space Requirements

Ensure you have sufficient disk space available:

  • A fully deployed local application in clean Docker will consume slightly more than 35 GB of WSL virtual disk space
  • The application folder after build (sources + artifacts) will occupy 4.5 GB

If there's insufficient space on your system drive (usually C:\), you can change the virtual disk location in Docker Settings → Resources → Advanced.

Docker WSL Integration

Make sure Docker is accessible from WSL:

  1. Go to Docker Settings → Resources → Advanced → WSL Integration
  2. Select the distribution where you'll be building and running the application
  3. Verify integration works by running this command in WSL:
    docker run hello-world
    

Common Issues and Solutions

Git Line Endings on Windows

Windows Git often automatically replaces line endings. Since most build scripts are .sh files, ensure your Windows checkout doesn't break them.

Solution options:

  • Checkout from WSL instead of Windows
  • Configure Git on Windows to disable auto-replacement:
    git config --global core.autocrlf false
    
    This disables auto-replacement for all repositories on your machine.

Elevated Privileges in WSL

Some commands in the instructions require elevated privileges when working in WSL. If you're using Ubuntu distribution, prefix commands with sudo:

sudo npm install -g @microsoft/rush

WSL Configuration

If the source code is located on a Windows NTFS drive, then edit the /etc/wsl.conf file in WSL (e.g., sudo nano /etc/wsl.conf) and add the following content if it doesn't exist:

[automount]
enabled = true
root = /mnt/
options = "metadata,umask=22,fmask=11"

[interop]
appendWindowsPath = false

However, we recommend storing the repository on a WSL disk, as this dramatically improves build and maintenance operations.

Running the Application

After these preparations, the build instructions should work without issues.

Port Conflicts

When starting the application (rush docker:up), some network ports in Windows might be occupied. You can fix port mapping in the \dev\docker-compose.yaml file.

Important: Depending on which port you change, you'll need to:

  1. Find what's using that port
  2. Update the new address in the corresponding service configuration

© 2025 Hardcore Engineering Inc.

Languages
TypeScript 51.1%
Svelte 28.2%
JSON-with-Comments 16.4%
JavaScript 1.5%
SCSS 1%
Other 1.6%