And what is your problem?

Just use . to find everything, which isn't related to your backend.

• '%' isn't a common known joker for searching for addresses, but '*' is (User centric sight).
• '%' is a SQL-Joker, which makes me hope for a SQL-Injection security hole ;-) (Security tester centric sight)

What do you mean by using "."?

Sorry, didn't understand your request properly last time.
I thought you wanted to get all entries in the address book, but you wanted all matching entries for a wildcard pattern.

What I suggested above was to go to the address book in question and type a single "." character into the search field.
You will get a list sorted by "Name" of all available addresses in this address book.
It's not what you want to do.

(Also for global address books from LDAP the maximum amount of addresses listed is limited via SOGoLDAPQueryLimit.)

The '%' character isn't working for global address books in LDAP, but only for address books in either mysql or postgesql.
In LDAP you have to use '*' as a wildcard.
So you have to use different search patterns depending on the backend.

That's definitely not user friendly.

:) Ok, my english is not really perfect ...

You will get a list sorted by "Name"
No, I didn't want any sorted list ... ;-)

And typing in a '.' shows the same list like '%'.

So you have to use different search
patterns depending on the backend.
That's definitely not user friendly.
Thats what I mean - the user is not interested in the differences between LDAP and SQL.

Summerized, in my opinion there are two problems:

• first, higher prio, a possible security hole by using '%' in a database driven address book (SQL Injection) (Should be filtered, only '*' allowed in SQL addressbooks)

• second, lower prio, the user "experience" by trying an asterisk, which gives no results. All people at our company tried '' at first, an when I told them about the percent '%' they looked a little bit astonished ("Ehm, why this?? I thought, i can use a ''??")

Maybe I produce only noise, I apologise ...

340ddf0ae6cf6a7aeb16d7b77f237bee7bff16a3 contains other safe measures. Closing for now since after an audit of the code, things seem clean.