And an additional question:

Why can a tick in generic access to (all) connections not solve this ?

Why must I also specify access to individual connections (or “select all” for convenience) ?

This looks like an over-implementation to me.

Cheers

I never used server apps, but I wonder this is because the default token life is set to a year?

Thanks Niels.

No, their expiration is set to 10 years, which is default, and the problem is remedied by setting token permissions (see my own comment).

So my understanding on this is that the “Access” at the top level gives access to be able to list the available connections to that user/token. If you create a new user with just the “Access” they can see the list in the FME Server UI (although they can’t see any specific connections).

I think It’s equivalent to “list”. For API tokens best practice is to just allow access to the connections that are actually used by that user. You don’t need to click the “Access” for the UI component. 
 

Hi Matt.

Sure, it would be best practice, but when this is suddenly introduced after more than a year since the server apps have been created, I cannot remember what connections are used, and so opt for the easy way of allowing all connections.

This is typically what happens when security measures are introduced in a bad manner.

But unfortunately it still doesn’t answer my question on whether, why, when, or how it was introduced.

Cheers

Yet another question is relevant:

Will FME Server update itself by itself when running ?

I.e. outside of being upgraded manually with a downloaded installer.

This is the only way such a change could be implemented imho, but I’ve never seen that any such measures have been documented or mentioned anywhere.

Cheers

No, FME Server wont update itself.

When creating an FME Server App the process is smart enough to detect a web connection, i.e., the created token should already have access to the required web connections.  

My assumption on what happened is one of two things. Both of which I think probably shouldn’t make a difference. 

1. Either the web connections somehow changed or maybe ownership changed - in my view this shouldn’t effect the tokens permission to access it, perhaps a new connection got published with the same names?.  
2. The user(s) trying to run the App already had/have an active FME Server session which didn’t have the required access. Again, the token used when running the app should always be the one configured, however, I could see the case where the active session somehow take precedent. 

Another thing which perhaps could have happened:

The connection from within the workspaces got modified to a new connection, this new connection got published, however, the token was never granted access to the newly created connection. 


There are some troubleshooting steps here:
https://support.safe.com/hc/en-us/articles/25407619843981-FME-Server-Connections-Runtime-Error-Unauthorized-request-by-user-due-to-lack-of-proper-permissions

Next time it happens you should try and figure out which connection is being used and see it the token already/still has permission to it.

Thanks Matt.

As I’ve written above, the server app and workspaces were old, and the connections used are very central and used by most workspaces on the server (web to itself, database to the main database). So they’ve not been re-uploaded or changed for a long time.

And the problem manifested itself from day to day, without any changes being made to any part.

The app calls a first “front” workspace, that calls the real second workspace with suitable parameters.

I just tried to create a new server app for the “front” workspace, and it did detect both connections, and did set access privilegies for both in the created token. So that’s good.

If it isn’t FME Server itself, or little green men, that’s causing trouble, I’ll just leave it as-is. At least I know where to remedy similar problems in the future.

I’ll give you “best answer” for the extensive documentation, which is very useful.

Cheers