Hello Deepa,
Static CBA does not need backend coding. Whenever the adaptation context can be fixed at startup and does not change later on you can stick with static CBA. Nevertheless you have to set the context somehow, and there are only two ways to do this without coding: URL- or Applicationparameters.
Regarding your concerns about modifying URLs. That's true, but you must never ever rely security on UI configuration (and CBA is only UI configuration). If there is some data shown in your application,
which only managers are allowed to see, you have to secure the data by appropriate authorization checks in the backend. Removing the displaying UI elements or UIBBs via any form of configuration, customizing, CBA, ... is not enough protection.
So securing your application needs backend coding, and best way to do it is as near to the database selection as possible. Securing the CBA adaptation context is not sufficient.
As already the feeder classes used in your FPM application should not expose unauthorized data to the user, there should be no need to protect the URL against changes.
If you want to do it anyway it is sufficient to make an authorization check best in your AppCC or in any feeder classes IF_FPM_GUIBB~INITIALIZE or better IF_FPM_MULTI_INSTANTIABLE~FPM_INITIALIZE method, if the global adaptation context matches the user's authorization.
The global adaptation context can be accessed via IF_FPM~MO_ADAPTATION_MANAGER->GET_ADAPTATION_CONTEXT. In your example you will get an entry with ROLE = MANAGER in the returned table and then you should do an authority-check for this.
If this check fails you should trigger a navigation to the error page.
But again, this is not the recommended way to do it, better is to secure the data much deeper in the business logic.
Best regards,
Christian
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.