It is the expected behavior and I wouldn't call it a bug or a feature. It is the same as if you are in FileMaker and you click on layouts, you and select another layout to go to.
Clearly you need to control security with privileges and if you have done this, no one can go to a layout to see data that they are not allowed to see even if you put the layout name in the URL.
Before WebDirect, we had Instant Web Publishing. FileMaker made a habit of storing everything within the "fmi/iwp" suffix after the domain name. This allowed FileMaker to play well with other web pages on the same server. They continued this with WebDirect with the suffix of "fmi/webd". But on the Mac, FileMaker WebDirect does not play well with other web pages and if they are going to take over the server, they might as well have gotten ride of the "fmi/webd" suffix. But I would prefer for them to start playing well with other Apache web pages in the future. So the "fmi/webd" suffix isn't too bad.
I have yet to see any official documentation on the URL formatting for WebDirect. We had a lot of documenation on IWP. Maybe that will come out in the future. It can be very useful to know how to format the URL to cause things to happen the way you want. And it can be dangerous if you don't have your security set up properly!
Thanks for your response Taylor. I'm having a hard time getting my mind around some things though that maybe you can provide some insight on.
After looking at the FM security via File->Manage->Security I clearly see that a privilege set can have No Access, Modifiable Access, or Viewable Access to a layout. Looks good, but...
I have a client who has a user who is new to their company and that client doesn't want to give the new user complete access to ALL functions (just a few-but the client wants to be able to change that at any time via checkbox). If this was the FileMaker client/server environment, I could roll my own application security in addition to the FM security based on my client's needs where they could check off functions they'd like a particular user to be able to do and through scripts, I could check to see if the user has the ability to perform a certain function. Because I usually provide a complete interface and hardly ever reveal the FileMaker interface to clients, it's easy to achieve my preferred method of locking out users from layouts since I can lock toolbars and have control of Custom Menus. But, in WebDirect, the problem I see is that after the user authenticates successfully, there is no granular way to keep them out of layouts since there is no way to base access to layouts via calculation in FM security.
This isn't a one size fits all scenario as privilege sets lend themselves to. I can't imagine having privilege sets for every possible situation is the answer. The fact that after a successful WebDirect authentication, a user could just substitute a different layout name in the URL, thus ignoring any custom business logic or proper navigation flow is quite startling.
Basically you are asking to create your own security interface and ask the client to not use the FileMaker security UI to make changes to privilege groups. That can be a tall order to do and create a lot of work when the security UI is a pretty good one. With scripting and all, you can add and remove users and you could use Active Directory to change groups a user belongs to and have predefined privilege groups. But there is no way of modifying a privilege group's access without using the FileMaker Security controls.
I guess the question is how important is it to you to hide the FileMaker interface and what is the purpose for doing so. I often limit access to FileMaker tool bars and interface for staff, but most of the companies I deal with want control of the Security and Schema and hiding those from them means locking any and all such changes into dependence on you. Maybe that is your goal. I think the bigger clients will not want to be so dependent on a developer and will require more access, particularly if you get in security plans and ISO certifications, etc. Obviously I do not know your business plan or why you want to hide the FileMaker tools and you might give some input on why you want to do that.
Don't get me wrong, the FM security UI is fine, just not specific to every application's needs. I always use the FM security for user accounts, but I usually limit users abilities based on application security logic (within the user's profile inside the application). Depending on the type of application, hiding the FM UI (toolbars, etc.) is important because I find it unnecessary to train a user on both the app I'm building and FileMaker as well. Having an app the performs all the same tasks that the FileMaker toolbar contains, but within the context of the custom application is pretty easy and not having the explain "watch what mode your in" to users who really couldn't be bothered understanding FileMaker intricacies just makes life easier.
Some common privilege sets I would use for any given app would be Admin, AppNameGuest, & AppNameUser. Admin is obvious, AppNameGuest really can't do anything but view (no export or printing), and AppNameUser can do everything with the exception of modifying layouts and scripts. Using custom security built into the app itself allows me to more tightly control who can do what within the app. For example, if someone doesn't have access to a particular layout, there is no way for them to get there (client/server environment).
Also, thinking about it, fortunately, there hasn't been a time when someone has asked for more access where I couldn't provide an interface for them to do what they wanted within the boundaries of the application either. That's the thing, FileMaker has always answered the call for almost every kind of challenge I've had over the years. Unfortunately, taking into account the various quarks and current limitations of WebDirect on top of the URL behavior I mentioned above, I don't think WebDirect will be the right fit for what I'm needing/wanting it to do. I can only hope that WebDirect evolves faster than the typical FMI pace of 15-18 month release cycles.
FileMaker is wonderful, but there are always a few issues here and there. And WebDirect is 1.0 feature and we already know of quite a few bugs that are being worked out. I expect it to do a lot of maturing in the new version. I will say it is vast improvement of IWP and a good step in the direction in browser connectivity. FileMaker also has PHP support, but it has always been almost there, but not quite as robust as in other databases. WebDirect gets me solutions developed a lot faster and for now we just have to take into account some limitations.
Maybe there will be some more fun stuff about WebDirect at Devcon this summer. Are you coming?
Taylor, I agree with you 100% about FileMaker. I'm very grateful for the product, but as it normally goes, give us an inch, and we'll want to take the whole mile. Yes, I'll be at Devcon. I'll have to seek you out as I'm sure by then they'll be much more to discuss! Thanks for you input on my original post.