What characters are forbidden in regular Innovator passwords?

Hi Angela,

Could you let me know what version you're using? I just tested using double quotes " in a password in release 33, and didn't see an issue. I can confirm that the section character (§) does appear to be invalid, however.

Hi Chris,

thanks for testing! I use Innovator 12SP7, but for this thread I use Release 2023 to make comparisons easier. Behavior is identical.

Your simple mention that " worked in your environment solved the problem. In my case both mentioned characters  " or § tricket me.

Root cause of the problem: German keyboard layout.

1. § is a less common char than I thought. It´s not part oft the 128 ASCII table. It´s not even common on keyboards worldwide. I really didn´t know that!  Clearly a German thing - even our keyboards have to reflect our love for bureaucracy by providing a dedicated key.

2. " is of course a super common character. But do I really get this char when I use MY keyboard? Well sometimes! For German keyboards it depends on the context. In a programming environment or in this forum I get the straight version ", but in other contexts I get the curly variants „ and “. These two are again not part of the regular ASCII table.

I made a quick test with a few other chars:

Work -->  %  $ & ? * ( ) + …

Fail -->  ö  ä  ß  €  SPACE

 So I assume we can use all regular ASCII 128 letters (without Spacebar). 

So I assume we can use all regular ASCII 128 letters (without Spacebar). 

This would be my assumption as well. I will verify once my test environments are set up, and I can look at the actual logic. 

Edit: It does appear that space characters are valid from my testing of Release 33. 

I confirm that Space DOES work! I probably mixed it up with another key yesterday.

We don't assign the passwords ourselves anyway, regular users reuse their Windows login data (LDAP). We've never had any problems with these.

I only use manual assigned passwords for additional system accounts. Typically for external accounts / tools that access Aras via Rest API. Each use case gets its own very restricted access, which only allows one specific activity.

I don't think you have to put a lot of effort into this. 99% of the keys on most international keyboards are ASCII 128 anyway. I guess in general nobody uses language specific letters for passwords. Thanks for doing the crosscheck of my mentioned keys! That helped a lot!

I confirm that Space DOES work! I probably mixed it up with another key yesterday.

We don't assign the passwords ourselves anyway, regular users reuse their Windows login data (LDAP). We've never had any problems with these.

I only use manual assigned passwords for additional system accounts. Typically for external accounts / tools that access Aras via Rest API. Each use case gets its own very restricted access, which only allows one specific activity.

I don't think you have to put a lot of effort into this. 99% of the keys on most international keyboards are ASCII 128 anyway. I guess in general nobody uses language specific letters for passwords. Thanks for doing the crosscheck of my mentioned keys! That helped a lot!