I am a backpack user and I am trying to change the language of the application.
Through the session I can send another language, but when it enters a route through backpack_url, it gets modified again to english. It may be caused by some middleware. Could you provide me with the middleware or provide some other solution? Thanks
I believe it depends on how you've set that language - if you've done that using a middleware, then indeed it might not apply on admin pages, since that middleware is not loaded there.
You could change which middleware admin pages use in your config/backpack/base.php, under middleware_class. So you could:
A) Add a custom middleware in the base config file, like App\Http\Middleware\SetLocaleAccordingToX;
B) Modify an existing middleware to also change the locale. You'll notice in the base config file that, all admin pages go through the App\Http\Middleware\CheckIfAdmin middleware too (for authorization purposes). You could set the local inside CheckIfAdmin.
Personally I think option A is cleaner - one middleware you reuse for both your front-facing and admin-facing pages (if that's your use case).
Related
I'm developing an extension for TYPO3 8.7 that queries an API for some data.
The frontend part works, although the API is called live at the moment.
Now I'd like to build a little backend module in which the integrator can at least manage the API credentials. Maybe also storage PIDs and other settings.
I guess storing data like these is usually done using TypoScript(?), but it would be nice to have a interface for storing settings of all kinds.
I rather guess I could create a database table and access it in the backend and frontend on a low level.
But before I do so I'd like to ensure that there is no other, designated way to do so. Maybe interact with the settings array somehow or whatnot.
I thought that storing configuration data would be a common usecase for backend modules. But I could not find any example for this.
Am I mislead about the usage of backend modules somehow?
TYPO3 Provides a Lot of Configuration Options.
in the Extension Manager
this allows you to set settings on a Systemwide Basis.
allows you to Set extension settings. using the ext_conf_template.txt this is easy for extension developers. and only accessible by admins. https://docs.typo3.org/typo3cms/CoreApiReference/ExtensionArchitecture/ConfigurationOptions/Index.html
Typoscrip Contants
this allows you to set configuration on a page basis, this is a great choice if you setup different settings on diffrent pages. or have a mutlipe sites in one TYPO3 Installation. there is an Interface "Constants Editor" in the Template Module which allows editors to set the settings of the constants.
Plugin / Flexform
the most common way an editor configures some settings. but they have to repeat them for every plugin.
Backend Modules
Backend modules are Designed for mor Complex task like manageing a News workflow. or giving inside-view into some process (status reports etc.) of cours they could be used to just store some simple settings. but its uncommen. and clutters the TYPO3 Backend Interface.
AdditionalConfiguration.php / ext_localconf.php this allows you to set very Low Level Configuration. if your configuration needs to be Availible only to Developer or needs to be Present in an Eary Bootstrapping Phase of TYPO3 this is a good choice
I your case, I would create a simple backend module and store the credentials in the Registry. This is easy to explain to the customer and you have the possibility to give access to that module to special user groups. By using the registry there's no need to create custom Tables.
Guide on how to create a backend module : https://docs.typo3.org/typo3cms/ExtbaseFluidBook/10-Outlook/2-Backend-modules.html
Guide on the Registry: https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/SystemRegistry/Index.html
I'm developing a wiki engine. Since this application can be usefull (at least for my company's private use) in its own it should be able to run as a standalone pyramid application, with its own graphical theme.
However a wiki feature could also be useful as part of a bigger project, and I would like to be able to include it into other pyramid applications.
I already found some pyramid features that could help me to achieve this but first I'm not sure whether it's the best way to do it and second some problems remain open.
Here are the potential issues I currently see:
templates: how to switch between the standalone mode and the hosted mode
host variables: event if we can reuse the host template, some variables may be needed to correctly render the templates but are not set by the guest (the wiki engine) application.
authentication: the guest app defines its own login system (based on pyramid_persona). Can the guest application reuse the host authentication system?
My current idea is to use the config.include() system of pyramid. In the wiki engine, in __init__.py I then define an include(config) method in addition the the main() method used for the standalone mode.
In the host application I then define a variable in the .ini file which points to the template file that the guest should use (ie base_template = hostapp:templates/wikibase.mako)
Inside the guest application, the includeme() method reads the base_template variable and overrides some global config.
Then each guest view work like this:
from pyramid.renderers import render
#view_config(route_name="display_wiki_page", renderer=Globals.base_template)
def view_wiki(request):
"""returns a formatted page content"""
page = request.matchdict['page']
content = get_raw_page_content_from_database(page)
page_formatted = render("wikiengine:templates/page_formatting_template.mako",
{'request': request, 'content': content} )
return {'page_formatted': page_formatted}
So from this point the base template can either be the one from the guest or the host application. Both will contain something like (in mako): ${page_formatted | n }
But this does not solve the problem of necessary host variables for the template to be rendered by the guest code. For example the host may need to have a hot_news variable that need to be displayed on each of the host pages, even the pages that host the wiki.
For this I plan use the event system, and add a subscriber for NewRequest or BeforeRender and set the needed variables here inside the request object.
Is this a correct approach ? Are there examples of what I'm trying to do?
Pyramid's configuration mechanisms make it very easy for clients of a module to override configuration. This is one of the most powerful parts of Pyramid compared to other popular web frameworks.
config.include() is a good approach to solving the problem. It allows the caller to override anything defined within the include.
Assets can be overridden using config.override_assets().
Sharing user information requires your module to either provide the user information or define a contract to which someone can conform allowing them to override your model.
Anyway this is obviously a huge topic. Highly modular apps written on top of pyramid include substanced, kotti, ptah, bookie, etc.
I have my shell application working and I now want to ensure that a user is logged in before anything else occurs. I have a working auth controller and associated database tables, etc.
I assumed that the best ay to do this was to put the identity test in the bootstrap, as I don't want to check for identity in each controller. Basically, I think I want to put code in the bootstrap that says if identity, then run the index otherwise, run auth. Is this the best way to do it in Zend? If not, what is the preferred method?
I was thinking Bootstrap because for every request of any type, I don't want to allow it if the user is logged in and of course, it would be best to chave this check only in ne place.
I have more commonly seen this in done via a plugin. These can be done at various stages of the Zend Application dispatch cycle. The most common set up I have encountered would be to put a check user login status plugin in at preDispatch.
Search the Zend documentation for preDispatch plugins, or have a look on Youtube as there are some good video tutorials that walk you through it.
An advantage to doing this is that in the future you may want to run some kind of functionality prior to the user authentication test. In such an instance you could put new functionality in a dispatchLoopStartup plugin.
Having said this, there is nothing really wrong with checking the user login status in the bootstrap - I have seen this done many times. It is possibly just tidier to user plugins as they are more repeatable in new applications.
This is just my opinion of course, but I hope this helps.
I am trying to simulate an intranet CMS and installed the eu_ldap extension for typo3. Unfortunately the downloaded guide is out of date, and the current manual is of very little use to a typo 3 beginner.
Is it possible to create nodes from within the extension or it has to be defined in the ldap server? Or can users can be created within typo3 then be authenticated via ldap or whether it has to be done on the OS. I'd like to build an intranet system and create users who can create resources using other extensions but I would like to structure access control also. In short I don't understand which functionalities are delegated to the extension and which have to be structured on the server side.
At the moment my best guess as to how to create the domains is to create a domain object with each page that acts as a domain root which will correspond to a node within the ldap (e.g. ou=Members) then create an ldap server object in typo 3 on that page, assuming this works (if it is the way to go about it) how can users be created and given acls? then added to this domain for instance?
The extension just provides the authentication service. So can connect the TYPO3 to your ldap by providing the connection data in the extension and then every login attempt is not checked on the TYPO3 side, but redirected to the ldap system. This just sends back whether the user is allowed to login and may provide some more information about the user and the assigned groups.
The ldap system does not know anything about the structure inside your TYPO3, but you can use the groups for access restrictions.
Most of the ldap extensions work like that and depending on whether you want to provide login to frontend, backend or both, there may also be better extensions for your case. You have to be a little more specific on
I'd like to build an intranet system and create users who can create resources using other extensions but I would like to structure access control also.
What kind of resources do you want them to create? Does that mean frontend or backend? What exactly do you want to have an access control for? Pages or content or plugins/extensions or backend modules?
I have a three applications that I would like to keep separate for manageability purposes. They run as a Plack server as suggested here, proxied behind nginx.
I would like to have a separate application to manage logins, and have that login and its authentication process shared across all other apps, with authorization done via roles.
I would like to use Catalyst::Authentication::Store::DBIx::Class for storage.
I have tried managing authentication at the Plack level with Catalyst::Authentication::Credential::Remote doing it at the Catalyst level (which would be ideal), but can't seem to make the login seen by the Catalyst apps.
Thanks for your help.
Sharing the store is easy -- you can either just use the DBIC session store and duplicate the config in all of the apps, or you can create a subclass of the DBIC store with a __PACKAGE__->config line containing the stuff that all of the apps have in common, and then specify your subclass in the session config.
As for the state -- you can use State::Cookie if the apps share a domain in common -- you just need to set the cookie_domain and/or cookie_path options in your session config so that the cookie gets set in a way that it will be visible to all of the apps, and set the cookie_name config option to the same thing in all apps, because otherwise they would all get different cookie names based on their different application class names.