Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a 'password' field type #1061

Closed
abass opened this issue Apr 10, 2015 · 4 comments
Closed

Create a 'password' field type #1061

abass opened this issue Apr 10, 2015 · 4 comments

Comments

@abass
Copy link

abass commented Apr 10, 2015

When you remove all permissions for a user, they still have access and can edit the MISC sub-category in settings on the backend which is terrible because some really important information that shouldn't be messed around with is there. To name a few plugins:

Google Analytics - Contains tons of keys & codes that will completely break it's dashboard functionality if changed.

Mailchimp - Contains the MailChimp API Key which would be very bad if changed by accident.

Disqus - Contains the Disqus API Site Key that would break comment section if changed.

@daftspunk
Copy link
Member

These are concerns that should be raised with the plugins themselves, as they are not secured correctly.

Leaving this open as a reference to fix it.

@daftspunk daftspunk self-assigned this Apr 11, 2015
@daftspunk daftspunk changed the title Can't block users from access to MISC sub-category in settings Create a 'password' field type Apr 4, 2016
@LarryBarker

This comment has been minimized.

@LukeTowers
Copy link
Contributor

@LArbearrr this is an expected behaviour, the model's hidden property is only for uses of toArray().

This is not a security concern as client's injecting fields in their own browser has no effect on what October sends the client in terms of model data and if you're talking about plugins extending the fields serverside, well it's much easier for them to just to steal_hashed_passwords(User::all()) then to muck about with changing a field type and going to a my account page, just to obtain their own hashed password.

@Samuell1
Copy link
Member

Samuell1 commented Jul 18, 2019

@w20k w20k closed this as completed Jul 18, 2019
@w20k w20k reopened this Jul 18, 2019
bennothommo added a commit that referenced this issue Jul 8, 2020
A field widget that allows for entering of sensitive information that can be revealed at the user's request - ie. API keys, secrets.

When a sensitive field that has been previously populated is loaded again, a placeholder is used instead of the real value, until the user opts to reveal the value. The real value is loaded via AJAX.

Credit to @tomaszstrojny for the original implementation.

Replaces #5062. Fixes #5061, #1850, perhaps #1061.

Co-authored-by: Tomasz Strojny <[email protected]>
bennothommo added a commit that referenced this issue Jul 8, 2020
A field widget that allows for entering of sensitive information that can be revealed at the user's request - ie. API keys, secrets.

When a sensitive field that has been previously populated is loaded again, a placeholder is used instead of the real value, until the user opts to reveal the value. The real value is loaded via AJAX.

Credit to @tomaszstrojny for the original implementation.

Replaces #5062. Fixes #5061, #1850, perhaps #1061.

Co-authored-by: Tomasz Strojny <[email protected]>
Co-authored-by: Luke Towers <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

6 participants