Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions .circleci/config.yml
Original file line number Diff line number Diff line change
Expand Up @@ -98,8 +98,8 @@ system-builder-ruby33: &system-builder-ruby33
ORACLE_SYSTEM_PASSWORD: threescalepass
NLS_LANG: AMERICAN_AMERICA.UTF8
TZ: UTC
MASTER_PASSWORD: p
USER_PASSWORD: p
MASTER_PASSWORD: superSecret1234#
USER_PASSWORD: superSecret1234#
LC_ALL: C.utf8
RAILS_ENV: test

Expand Down
8 changes: 8 additions & 0 deletions .gitleaks.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
[allowlist]
description = "Global Allowlist"

# Ignore based on any subset of the file path
paths = [
'''test/unit/authentication/by_password_test.rb''',
'''test/integration/admin/api/buyers_users_controller_test.rb'''
]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had to add this so our password leak system allows me to commit.

6 changes: 3 additions & 3 deletions app/controllers/admin/api/settings_controller.rb
Original file line number Diff line number Diff line change
Expand Up @@ -12,9 +12,9 @@ class Admin::Api::SettingsController < Admin::Api::BaseController
before_action :validate_enforcing_sso_allowed, only: [:update]

ALLOWED_PARAMS = %i[
useraccountarea_enabled hide_service signups_enabled account_approval_required strong_passwords_enabled
public_search account_plans_ui_visible change_account_plan_permission service_plans_ui_visible
change_service_plan_permission enforce_sso
useraccountarea_enabled hide_service signups_enabled account_approval_required public_search
account_plans_ui_visible change_account_plan_permission service_plans_ui_visible change_service_plan_permission
enforce_sso
].freeze

# Settings Read
Expand Down
2 changes: 1 addition & 1 deletion app/controllers/partners/providers_controller.rb
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ def account_params
def user_params
{
signup_type: partner.signup_type,
password: permitted_params[:password].presence || SecureRandom.hex,
password: permitted_params[:password].presence,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The user is valid without a password when it's an SSO user. So there's no need to enforce a random password. Also, this random password is not shown to the caller anywhere, so it couldn't be used anyway.

After this change, The SSO users for partners don't have a password, the same as any other SSO user in the project.

email: permitted_params[:email],
first_name: permitted_params[:first_name],
last_name: permitted_params[:last_name],
Expand Down
12 changes: 6 additions & 6 deletions app/controllers/partners/users_controller.rb
Original file line number Diff line number Diff line change
Expand Up @@ -22,19 +22,19 @@ def destroy
def create
@user = @account.users.build
@user.email = params[:email]
@user.password = SecureRandom.hex
@user.password = params[:password].presence
Copy link
Contributor Author

@jlledom jlledom Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same, no password required.

@user.first_name = params[:first_name].presence
@user.last_name = params[:last_name].presence
@user.open_id = params[:open_id].presence
@user.username = params[:username]
@user.signup_type = :partner
@user.role = :admin
@user.activate!
if @user.save
render json: {id: @user.id, success: true}
else
render json: {errors: @user.errors, success: false}
end
@user.save!

render json: {id: @user.id, success: true}
rescue StandardError
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why rescue instead of rely on @user.save return value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the previous call to @user.activate! can raise an exception, which was uncaught.

render json: {errors: @user.errors, success: false}, status: :unprocessable_entity
end

private
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ def user_params
end

def current_password_verification
return true unless current_user.using_password?
return true unless current_user.already_using_password?

unless current_user.authenticated?(user_params[:current_password])
flash.now[:danger] = t('.wrong')
Expand Down
2 changes: 1 addition & 1 deletion app/controllers/provider/passwords_controller.rb
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ class Provider::PasswordsController < FrontendController
before_action :passwords_allowed?

def new
return redirect_back_or_to(root_path), danger: t('.has_password') if current_user.using_password?
return redirect_back_or_to(root_path), danger: t('.has_password') if current_user.already_using_password?

reset_session_password_token
token = current_user.generate_lost_password_token
Expand Down
7 changes: 6 additions & 1 deletion app/javascript/src/Login/utils/validations.ts
Original file line number Diff line number Diff line change
@@ -1,5 +1,10 @@
import validate from 'validate.js'

// IMPORTANT: This STRONG_PASSWORD_MIN_SIZE constant is duplicated from the backend.
// The source of truth is app/lib/authentication/by_password.rb. If this constant changes in Ruby,
// you must update it here as well. Do not modify it without updating the backend first.
const STRONG_PASSWORD_MIN_SIZE = 15

const loginConstraints = {
username: { presence: { allowEmpty: false, message: 'Email or username is mandatory' } },
password: { presence: { allowEmpty: false, message: 'Password is mandatory' } }
Expand All @@ -12,7 +17,7 @@ function validateLogin (fields: Record<keyof typeof loginConstraints, string>):
const changePasswordConstraints = {
password: {
presence: { allowEmpty: false, message: 'Password is mandatory' },
length: { minimum: 6 }
length: { minimum: STRONG_PASSWORD_MIN_SIZE }
},
passwordConfirmation: {
presence: { allowEmpty: false, message: 'Password confirmation is mandatory' },
Expand Down
69 changes: 44 additions & 25 deletions app/lib/authentication/by_password.rb
Original file line number Diff line number Diff line change
Expand Up @@ -4,38 +4,31 @@ module ByPassword
extend ActiveSupport::Concern

# strong passwords
SPECIAL_CHARACTERS = '-+=><_$#.:;!?@&*()~][}{|'
RE_STRONG_PASSWORD = /
\A
(?=.*\d) # number
(?=.*[a-z]) # lowercase
(?=.*[A-Z]) # uppercase
(?=.*[#{Regexp.escape(SPECIAL_CHARACTERS)}]) # special char
(?!.*\s) # does not end with space
.{8,} # at least 8 characters
\z
/x
STRONG_PASSWORD_FAIL_MSG = "Password must be at least 8 characters long, and contain both upper and lowercase letters, a digit and one special character of #{SPECIAL_CHARACTERS}.".freeze
STRONG_PASSWORD_MIN_SIZE = 15

included do
# We only need length validations as they are already set in Authentication::ByPassword
has_secure_password validations: false

validates_presence_of :password, if: :password_required?
before_validation :normalize_password, if: :validate_password?

validates_presence_of :password, if: :validate_password?

validates_confirmation_of :password, allow_blank: true

validates :password, format: { :with => RE_STRONG_PASSWORD, :message => STRONG_PASSWORD_FAIL_MSG,
if: -> { password_required? && provider_requires_strong_passwords? } }
validates :password, length: { minimum: 6, allow_blank: true,
if: -> { password_required? && !provider_requires_strong_passwords? } }
validates :password, length: { minimum: STRONG_PASSWORD_MIN_SIZE }, if: :validate_strong_password?

validates :lost_password_token, :password_digest, length: { maximum: 255 }

attr_accessible :password, :password_confirmation
attr_accessible :password, :password_confirmation, as: %i[default member admin]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to fix a mass-assignment error from PUT /admin/api/users/{id}.xml. Since the endpoint calls the update with role: :admin. The password was excluded from mass-assignment, because it only allowed the default role.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand... if there is no as: argument here, doesn't it mean that the role set in :as when assigning attributes doesn't matter?


scope :with_valid_password_token, -> { where { lost_password_token_generated_at >= 24.hours.ago } }

alias_method :authenticate_without_normalization, :authenticate

def authenticate(password)
authenticate_without_normalization(password&.unicode_normalize(:nfc))
end
alias_method :authenticated?, :authenticate
end

Expand All @@ -45,8 +38,16 @@ def find_with_valid_password_token(token)
end
end

def password_required?
signup.by_user? && (password_digest.blank? || password_digest_changed?)
def validate_password?
# The password changed or it's a new record that must provide a password
will_save_change_to_password_digest? || (new_record? && signup.by_user?)
end

def validate_strong_password?
return false if Rails.configuration.three_scale.strong_passwords_disabled
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it will be much better to set the STRONG_PASSWORD_MIN_SIZE based on this setting than overriding it here.

Because you said in a comment:

Nah, I don't like that. I prefer UI and backend to be in sync, the opposite would be pretty confusing for client ad for future us.

But this setting is essentially doing the same - UI will still want strong passwords but backend will allow weaker.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this setting is essentially doing the same - UI will still want strong passwords but backend will allow weaker.

You're right on this

I think it will be much better to set the STRONG_PASSWORD_MIN_SIZE based on this setting than overriding it here.

What do you mean by "overriding here"? overriding the setting? Also, if we set STRONG_PASSWORD_MIN_SIZE based on the setting, we still need this method to check for sample data.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I meant that this specific line overrides STRONG_PASSWORD_MIN_SIZE based on a configuration setting. So my suggestion was to simplify by setting STRONG_PASSWORD_MIN_SIZE based on a configuration value instead of moving the logic here.

Agreed that we still need the sample data check. Hopefully later we get rid of it by also generating strong password for John Doe.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then we would need to get rid of john doe default password and signup_types before implementing your suggestion

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can get rid of this specific line regardless of John Doe.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been trying but I don't think it's worth it right now. Having the setting checked in the method is pretty convenient for tests, so I can stub the value and easily see the different behavior. However, if we move the logic to the macro, then the setting is only read once when loading the code, so stubbing the setting has no effect, which leads to a few tests failing.

I prefer to not spend the time redefining tests right now, when we actually get rid of sample data, I'll remove the validate_strong_password? method and then I'll worry about the tests.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, sure. Even if it stays, it will not be a big issue.

return false if signup.sample_data?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return false if signup.sample_data?
return false if signup.sample_data? && !Rails.env.production?

Follow up on previous question about sample data ending up in production, I would imagine the logic to something like this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of this, is we agreed to not allow weak passwords for sample dat ain production, I'd prefer to completely remove the :sample_data signup type. I wouldn't be needed anymore.

Copy link
Contributor

@akostadinov akostadinov Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be happy not having :sample_data login type. After all the idea behind sample data is to look like real data and being a separate type is not it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it'd be good to remove the sample data signup type, but that would imply all the additional logic: Creating Jonh Doe with a random password, send it via internal message to admin, and updating the places where that password is visible, like the CMS toolbar.

@mayorova WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I vote for keeping it like it is now - John Doe with 123456 password still being valid. I think it's good to keep the changes less disruptive for the user.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can also generate default passwords derived from e.g., buyer id and SECRET_KEY_BASE derivative and we can present that password to the provider in the UI when viewing the user.

  • provider opens the user
  • system detects that this is the first default user John Doe
  • system generates the default password
  • checks whether it matches the user
  • warns that the user has the default password of "..." OR reports that the password has changed from the default

I think this will be a good UX while keeping things way more secure.


validate_password?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to call this again?
As we have

      validates_presence_of :password, if: :validate_password?
      validates :password, length: { minimum: STRONG_PASSWORD_MIN_SIZE }, if: :validate_strong_password?

It means that most for when strong password is used (most of the time) validatee_password? will be called twice?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be called not twice, but three times, because it's also called by:

before_validation :normalize_password, if: :validate_password?

But I think that's fine because it's only called when updating a user, I don't know how common is that but doesn't seem supper common. Also, it makes the code more clear, otherwise, it would be confusing, e.g. a scenario where validate_password? is false but validate_strong_password? is true. Like for instance when you are modifying a user attribute which is not the password. What would happen then? would we validate the length of a password when that attribute is not involved in the update? Even more, password is a virtual attribute so I don't really know what would be there at the validation moment, most probably nil I guess.

This way validate_password? and validate_strong_password? always have consistent values.

end
Comment on lines +41 to 51
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This replaces password_required? Because it was pretty confusing:

  • Being called from views to decide whether making password inputs required. IMO that's wrong, password inputs are required or not according to their purpose, not to some computed value.
  • Being called also to decide whether validate the password or not. Which was wrong as well, since it didn't match all scenarios.

The new methods are tested and return proper values for all known scenarios.


def just_changed_password?
Expand All @@ -59,9 +60,10 @@ def expire_password_token

def generate_lost_password_token
token = SecureRandom.hex(32)
return unless update_columns(lost_password_token: token, lost_password_token_generated_at: Time.current)
self.lost_password_token = token
self.lost_password_token_generated_at = Time.current

token
token if save
end

def generate_lost_password_token!
Expand All @@ -81,12 +83,12 @@ def update_password(new_password, new_password_confirmation)
save
end

def using_password?
password_digest.present?
def already_using_password?
password_digest_in_database.present?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wait, if password_digest was set but not yet in the database, shouldn't we still return true here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was causing issues in the user edit form. If I recall correctly, on some scenarios the form required the user to provide their current password in situations where that password was still not persisted, so it couldn't work.

I think it's correct this way. We only consider a user is using a password when it indeed has a password in DB.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, fine, if not too annoying, I'd suggest renaming the method to already_using_password? to make this immediately obvious.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I renamed it everywhere except in the User liquid drop, to not break existing dev portals 8b6697b

end

def can_set_password?
account.password_login_allowed? && !using_password?
account.password_login_allowed? && !already_using_password?
end

def special_fields
Expand All @@ -96,5 +98,22 @@ def special_fields
def reset_lost_password_token
self.lost_password_token = nil
end

raise "FIXME" if Gem::Version.new(Rails.version) >= Gem::Version.new("8.1")
# To avoid all this logic, from Rails 8.1+ we can use
# `ActiveModel::Attributes::Normalization`, so `normalizes` method
# works with virtual attributes like `password` and `password_validation`
# and normalizes on assignment rather than before_validation
def normalize_password
if password.present?
normalized = password.unicode_normalize(:nfc)
self.password = normalized unless password == normalized
end

if password_confirmation.present?
normalized_confirmation = password_confirmation.unicode_normalize(:nfc)
self.password_confirmation = normalized_confirmation unless password_confirmation == normalized_confirmation
end
end
end
end
2 changes: 1 addition & 1 deletion app/lib/logic/provider_signup.rb
Original file line number Diff line number Diff line change
Expand Up @@ -71,7 +71,7 @@ def ensure_users(count)
def signup_user
email_part = email.split('@')
user_attributes = { email: "#{email_part[0]}+test@#{email_part[1]}", username: 'john', first_name: 'John',
last_name: 'Doe', password: '123456', password_confirmation: '123456', signup_type: :minimal}
last_name: 'Doe', password: '123456', password_confirmation: '123456', signup_type: :sample_data}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order to exclude "John Doe" from strong password requirement, I added a new signup type :sample_data to identify it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The question is, shouldn't we prevent sample weak passwords in production environment? I think we discussed this somewhere, about how to notify provider of the sample buyer user account. e.g. email/internal messaging.

But I'm not sure we came to an agreement.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed this via slack, I even suggested to get rid of John Doe, we agreed on keeping the sample data. About the sample data having a weak password, that's another story. I remember you mentioned about sending the password to admin via internal messaging, but nothing was agreed at the end.

signup_params = ::Signup::SignupParams.new(plans: [], user_attributes: user_attributes, account_attributes: { org_name: 'Developer' })
::Signup::DeveloperAccountManager.new(@provider).create(signup_params)
end
Expand Down
2 changes: 1 addition & 1 deletion app/lib/signup/developer_account_manager.rb
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ def persist!(result, plans, defaults)

# TODO: Temporary here. A new object should have the responsability to activate and approve when needed
# As part of THREESCALE-1317
result.user_activate! if result.user_activate_on_minimal_signup?
result.user_activate! if result.user_activate_on_minimal_or_sample_data?
end
end
end
2 changes: 1 addition & 1 deletion app/lib/signup/result.rb
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ def local_initialize; end
attr_reader :user, :account

delegate :approve, :approve!, :approved?, :approval_required?, :make_pending!, to: :account, prefix: true
delegate :activate, :activate!, :active?, :activate_on_minimal_signup?, to: :user, prefix: true
delegate :activate, :activate!, :active?, :activate_on_minimal_or_sample_data?, to: :user, prefix: true
delegate :id, to: :account

def valid?
Expand Down
15 changes: 6 additions & 9 deletions app/models/user.rb
Original file line number Diff line number Diff line change
Expand Up @@ -344,14 +344,6 @@ def provider_id_for_audits
account.try!(:provider_id_for_audits) || provider_account.try!(:provider_id_for_audits)
end

def provider_requires_strong_passwords?
# use fields definitons source (instance variable) as backup when creating new record
# and there is no provider account (its still new record and not set through association.build)
if source = fields_definitions_source_root
source.settings.strong_passwords_enabled?
end
end
Comment on lines -347 to -353
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dead code AFAIK


protected

def account_for_sphinx
Expand Down Expand Up @@ -436,6 +428,11 @@ def minimal?
signup_type == :minimal
end

def sample_data?
# This is true only for John Doe
signup_type == :sample_data
end

def api?
signup_type == :api
end
Expand All @@ -457,7 +454,7 @@ def cas?
end

def machine?
minimal? || api? || created_by_provider? || open_id? || cas? || oauth2?
minimal? || sample_data? || api? || created_by_provider? || open_id? || cas? || oauth2?
end

def by_user?
Expand Down
4 changes: 2 additions & 2 deletions app/models/user/states.rb
Original file line number Diff line number Diff line change
Expand Up @@ -75,8 +75,8 @@ def make_activation_code
self.activation_code = self.class.make_token
end

def activate_on_minimal_signup?
minimal_signup? && password.present? && !account.try!(:bought_account_plan).try!(:approval_required?)
def activate_on_minimal_or_sample_data?
(minimal_signup? || signup.sample_data?) && password.present? && !account.try!(:bought_account_plan).try!(:approval_required?)
Comment on lines +78 to +79
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method determines whether the new user must be automatically activated or not. I added the :sample_data case to it. Sample user must be activated by default.

end

def generate_email_verification_token
Expand Down
1 change: 0 additions & 1 deletion app/representers/settings_representer.rb
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,6 @@ module SettingsRepresenter
property :hide_service
property :signups_enabled
property :account_approval_required
property :strong_passwords_enabled
property :public_search
property :account_plans_ui_visible
property :change_account_plan_permission
Expand Down
2 changes: 1 addition & 1 deletion app/views/buyers/accounts/new.html.erb
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@
</div>
<%= form.fields_for [:user, @user ] do |user| %>
<%= user.user_defined_form %>
<%= user.input :password, as: :patternfly_input, required: true %>
<%= user.input :password, as: :patternfly_input, input_html: { type: 'password' }, required: true %>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Password input was in clear text

<% end %>
</section>

Expand Down
4 changes: 2 additions & 2 deletions app/views/buyers/users/edit.html.erb
Original file line number Diff line number Diff line change
Expand Up @@ -13,8 +13,8 @@
<% end %>

<%= form.inputs :name => "Change Password" do %>
<%= form.input :password, required: true, input_html: { autocomplete: 'off' } %>
<%= form.input :password_confirmation, required: true, input_html: { autocomplete: 'off' } %>
<%= form.input :password, required: false, input_html: { autocomplete: 'off' } %>
<%= form.input :password_confirmation, required: false, input_html: { autocomplete: 'off' } %>
Comment on lines +16 to +17
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was wrong, there's no scenario when it's required to change a password in this form.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, it was a "fake" requirement, the form submit was working without provided values.

<% end -%>

<% if can? :update_role, @user %>
Expand Down
4 changes: 2 additions & 2 deletions app/views/provider/admin/account/users/_form.html.erb
Original file line number Diff line number Diff line change
Expand Up @@ -3,8 +3,8 @@
<% end %>

<%= form.inputs :name => "Change Password" do %>
<%= form.input :password, :required => true %>
<%= form.input :password_confirmation, :required => true %>
<%= form.input :password, :required => false %>
<%= form.input :password_confirmation, :required => false %>
<% end -%>

<% if can? :update_role, @user %>
Expand Down
18 changes: 5 additions & 13 deletions app/views/provider/admin/user/personal_details/edit.html.slim
Original file line number Diff line number Diff line change
Expand Up @@ -3,13 +3,6 @@
- content_for :javascripts do
= stylesheet_packs_chunks_tag 'pf_form'

- if current_user.can_set_password? && !current_account.settings.enforce_sso?
- content_for :page_header_alert do
br
= pf_inline_alert t('.set_password_html', href: new_provider_password_path), variant: :info

- using_password = current_user.using_password?

div class="pf-c-card"
div class="pf-c-card__body"
= semantic_form_for current_user, builder: Fields::PatternflyFormBuilder,
Expand All @@ -20,13 +13,12 @@ div class="pf-c-card"

= form.inputs 'User Information' do
= form.user_defined_form
- if using_password
= form.input :password, as: :patternfly_input,
label: t('.new_password_label'),
required: current_user.password_required?,
input_html: { value: '', required: current_user.password_required? }
= form.input :password, as: :patternfly_input,
label: t('.new_password_label'),
required: false,
input_html: { value: '', type: 'password', required: false }

- if using_password
- if current_user.already_using_password?
= form.inputs "Provide your current password and update your personal details" do
= form.input :current_password, as: :patternfly_input,
required: true,
Expand Down
4 changes: 0 additions & 4 deletions app/views/sites/usage_rules/edit.html.slim
Original file line number Diff line number Diff line change
Expand Up @@ -27,10 +27,6 @@ div class="pf-c-card"
input_html: { disabled: settings.approval_required_disabled? },
hint: account_approval_required_hint(current_account)

= form.inputs 'Users'
= form.input :strong_passwords_enabled, as: :patternfly_checkbox,
hint: t("formtastic.hints.settings.strong_passwords_enabled", strong_password_definition: strong_password_definition)

= form.inputs 'Search'
= form.input :public_search, as: :patternfly_checkbox

Expand Down
1 change: 1 addition & 0 deletions config/examples/settings.yml
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,7 @@ development:
force_ssl: false
report_traffic: false
secure_cookie: false
strong_passwords_disabled: true

test:
<<: *default
Expand Down
Loading