Wim Decorte

That's a common misconception, but it is a critical one. Certs are not exclusively meant for anything exposed to the internet. Certs are used to encrypt the traffic and validate the destination's identity and that is equally critical for traffic that never leaves the network. Read any security and data breach report and you'll find they all state the same (and have stated for many years): that the vast majority of breaches come from inside the network, not from outside the network. Thinking that you do not need certs because it is all internal is very very faulty. Since certs

We had part of this conversation already on community.claris.com... don't use a self-signed cert and certainly don't use it to try and sign "localhost' as a domain. Localhost has special meaning in networking. The problem with self-signed certs is that they may not be trusted by the other machine you're trying to connect from, which defeats the purpose of using HTTPS and SSL to begin with. So if you insist on using self-signed certs, make absolutely certain that you have that piece working without getting the security warning first. The fact that your browser stores it in the keychain

If you have asked for groups in the scope then it looks like your app on the Auth0 side is not configured to return groups. That particular string is only valid for my Auth0 app; you have to configure yours on the Auth0 app side and then use it in your dbs_config.xml file Just verified that with the latest ETS build of FMS Linux, that Auth0 authentication works, just like with the current Windows and macOS servers. It should work on your FMS17 box too once you have made the final tweaks on the Auth0 side of things.

One of the main things to keep in mind about Auth0 is that they insist on namespacing the groups claim. When you inspect the id_token they return you'll see this (line 2) So you have to adjust your changes in the FMS dbs_config.xml file accordingly. FMS typically just expects 'groups' as the key name for the array of groups.

Yep, that old preview version of FMS Linux did not support External Authentication: If you are in the ETS beta testing program you should have access to a more recent version that does. If you are in ETS, ping me in the ETS group on community.claris.com and I can help you set it up for Auth0. If you are not then we should pick either Windows or macOS to help you set this up. Let us know.

Late in the day here so I'll reply in full tomorrow. But I don't believe that early build of FMS Linux supported external authentication of any kind. I'll try tomorrow with a later build. It should work just fine with the current versions of FMS17, 18 and 19 on macOS or Windows if you want to set it up there and not wait for when the Linux version gets released.

Are you using the preview build of FMS CentOS? If so what is the exact build number? If not, what version of FMS are you using and on what platform? From your description it seems like you actually get to Auth0 after you click the MS button and you successfully authenticate there, but the redirect doesn't work? Have you tested your setup with something like https://oidcdebugger.com/ and Postman for the 2nd leg of the OAuth? Are you attempting group-based auth or individual account auth? The white papers that you'll find here written by Steven Blackwell and myself expla

Careful now - that statement is too generic; SSO only works under very strict conditions, namely only in a all-Windows line-up. If the users are on macOS workstations for instance SSO won't work. If the users do not log into their Windows workstations with an AD account then SSO won't work either. The question here was not about how to set up EA, but about not being able to use the "DisplayName" on an AD account. Whereas for instance on macOS with Open Directory you can use both the user's long name and the short name, which is what prompted the question.

Pinging is not a good connectivity test. Nobody in their right mind still has internet equipment that responds to pings. Given that you state that your networking experience is limited, and given the importance of getting a well protected firewall set up; I would find a trusted local networking guy.

No. What you put in the login name in AD is all you can use: Note that this also shows that the user can use 3 different login syntaxes: user DOMAIN\user user@domain FM will accept all 3 of them but your Get(AccountName) will return exactly what the user entered. So you may need to do some post processing of the Get(Accountname) output

That's right, but operations on the data in a field very often will force casting into underlying field's data type. Which is why it is often important to know the field's data type so that you know what it is supposed to be.

If it is a field: by querying the FileMaker_Fields metatable with executeSql(), or by using the FieldType() design function. If it is a variable: you can't. Much like other environments where you declare a variable 'untyped' by doing something like 'var myVariable', FM works the same. Except that you don't have a TypeOf() equivalent. As a developer you need to know what you put in the variable. When in doubt just use the right GetAs...() function.

That has nothing to do with data types, what that speaks to is that FM is permissive in that it does not prohibit the user from inputting the wrong data type into fields, it leaves it up to developer to put validation rules in place. FM does NOT treat everything as text as you claimed. Even a variable will maintain the correct data type of what you set into it, including container data.

Absolutely, under no circumstances, make a direct path from finder to where FMS stores its containers. Container data is strictly for FMS to manage and no user should be able to have direct non-FM access to the container data files. With that out of the way, I'm a little confused about your current setup. How is the mp3 loaded into the container field from the ftp site? Can you describe the mechanics here? Perhaps show the script that does it?

When you make statements about what is better than an alternative, please qualify the statement. Why is 'choose' better than IF() or CASE() for you? If two or three different approaches produce the same result, how do you select the one you want to use? Performance? What if it doesn't matter and makes the code less readable?