ElanoryaJewelry AI · Account
A password is stored exactly as you typed it, spaces included
The app does not tidy up what you type. A space before the first character or after the last one is accepted and becomes part of the password. The screen warns you about it, and the form still submits. Changing the password later does not sign you out on the device you change it from.
What the app does with the characters you type
The app does not trim your password. If a space sits before the first character or after the last one, it is accepted and stored as part of the password.
That is a deliberate choice rather than an oversight. A form that quietly removed characters would be changing a secret without telling you, so the app keeps the value as typed and tells you instead.
The consequence arrives later, at sign-in, where the same space has to be typed again. The code that raises the warning is written around the expectation that it will not be.
Why a password you are certain of can still be refused
Four separate things can be true on the screen in front of you. Only the first is about the characters themselves.
- The stored password may contain a character you cannot see.
- A leading or trailing space typed at sign-up is part of the password. Sign-in has to reproduce it.
- The account may have no password at all.
- An account opened with Google or Apple can exist without one. The app asks the server whether a password exists rather than deciding for itself.
- The app's answer to that question can be briefly wrong.
- Immediately after a social sign-in the app assumes a password exists and then reads the real state. If the read does not succeed, you stay signed in but the password state can remain wrong until a later read succeeds. The client code does not reveal how often this occurs.
- What the server does with a failed attempt is not visible from this surface.
- This description covers what the client shows. Attempt handling and other server-side identity rules are outside it, and this page does not state them in either direction.
Which of these matches what is on your screen
Each row is a different cause and needs a different move.
| Situation | Choose | Why |
|---|---|---|
| You are sure the password is right and the sign-in is refused. | Try the value again with a space at the start, then with a space at the end. | The password was stored exactly as typed, and neither space is visible in the field. |
| You created the account with Google or Apple and never chose a password. | Continue with the same provider instead of looking for a password to recover. | An account created that way can have no password, so there is nothing to reset. |
| A password field is asking for something you do not have. | Leave the screen, let the app reach the server again, and come back to it. | The app's reading of whether the account has a password can stay wrong until a refresh succeeds. |
| You want to change the password but have unfinished work open. | Change it here, on this device. | The device the change is made from is not signed out; the session stays open. |
| You also use a second phone or tablet for the same account. | Plan to sign in again there, without expecting a time you can quote. | Dropping the other devices is server behaviour that the app relays; when each device notices is not something this surface can state. |
Changing the password does not end the session you are in
The client is explicit about this: on a password change the calling session is kept alive on purpose, and the other devices are dropped.
In practice that means the phone or tablet you make the change from does not return you to the welcome screen. You carry on with whatever was open.
The drop on the other devices belongs to the server. The app passes the outcome on and nothing more, so this page states neither a moment at which those devices stop working nor any session lifetime or expiry figure — none of that is readable here.
What this surface shows, and what it does not
The left column is the question a locked-out seller actually asks. The right column is where this page stops.
| Question | What the client shows | What it does not show |
|---|---|---|
| Is a typed space kept? | Yes — the password is stored exactly as typed | Any rule the server applies to the value itself |
| Does changing the password sign me out here? | No — the session on this device stays open | Any session lifetime, refresh interval or expiry figure |
| What happens to my other devices? | They are dropped | When they notice; the app only relays the server's behaviour |
| Does my account have a password? | The app reads the answer from the server after a social sign-in | How often that answer is briefly wrong before a refresh succeeds |
The boundaries of this description
Each of these is either owned by another page or outside what the client can prove.
- What the server does after repeated failed attempts. Server-side identity and session rules are not readable from this surface, and this page states nothing about them in either direction.
- Any session lifetime, refresh interval or expiry figure.
- The moment at which a dropped device stops being signed in.
- What signing out removes from a phone, and what the device list does — a separate page on signing out covers both.
- The steps of the account deletion screen. That is its own page; this one only explains why an account may have no password for such a screen to ask for.
- Whether Google or Apple sign-in is switched on in the app you are holding. The client code shows only that a provider is drawn when it has been configured, not what the configuration is.
How this was checked
These statements were read from the Jewelry AI mobile client in August 2026. The untrimmed password and its non-blocking warning come from apps/jewelry-mobile/src/features/auth/auth-validation.ts, where the comment records that a leading space is accepted and stored and that the user will not retype it at sign-in.
The session that survives a password change, and the password-state reading taken after a social sign-in, come from apps/jewelry-mobile/src/features/auth/auth-provider.tsx, where the comments record that the calling session is kept alive while other devices are dropped, and that a Google-only user may have no password so the assumed value is replaced by the real one.
Server behaviour is outside that reading. Where the server decides, this page says so rather than inferring a rule from the client.
Questions
Can a single space really lock me out of my own account?
Yes. The app does not trim what you type, so a space at the start or the end of the password becomes part of it. Signing in later means typing that space again. The screen warns you when it sees one, but the warning does not stop the form from being sent.
Will changing my password sign me out of the app?
Not on the device you change it from — that session stays open and you continue where you were. Your other devices are dropped. That drop is server behaviour that the app relays, so this page does not state when each of those devices will show it.
I signed in with Google and the app is asking for a password. What now?
An account opened with Google or Apple can have no password at all. Straight after a social sign-in the app assumes there is one and then reads the real state from the server; if that read does not succeed, the state can stay wrong until a later one does. Leaving the screen, letting the app reach the server again, and returning is the practical move.
Is there a minimum length, or a limit on how many times I can try?
This page cannot tell you. What is described here is the behaviour of the app on your phone, and rules of that kind live on the server, outside what the client shows. Rather than guess, this page states nothing about them in either direction.