I have a few of their projects on Symfony 2. On one of them today itch to do a total upgrade to the newest versions. Prior to that, everything worked perfectly. And the projects themselves, and sonata admin and authorization.
After the upgrade, I did not knurl old configs, and carefully read the manuals for all the vendors, and prescribed all over again. There were a few problems, but the project has started pretty quickly. The site works, authorization works, not only works admin panel. Today, a day fumbling, and can not understand why I have the admin screen blank.
in /src/Itfrogs/SiteBundle/Resources/config/services.yml
...
sonata.admin.dictionary.group:
class: Itfrogs\SiteBundle\Admin\Model\DictionaryGroupsAdmin
tags:
- { name: sonata.admin, manager_type: orm, group: Content, label: Dictionary Group }
arguments:
- ~
- Itfrogs\SiteBundle\Entity\DictionaryGroup
- ~
calls:
- [ setTranslationDomain, [ItfrogsSiteBundle]]
...
in main config.yml
...
sonata_block:
default_contexts: [cms]
blocks:
sonata.admin.block.admin_list:
contexts: [admin]
#sonata.admin_doctrine_orm.block.audit:
# contexts: [admin]
sonata.block.service.text:
sonata.block.service.action:
sonata.block.service.rss:
sonata.media.block.media:
sonata_admin:
dashboard:
blocks:
-
position: left
type: sonata.admin.block.admin_list
...
I think it's basic. Rest on a manual. The class Itfrogs\SiteBundle\Admin\Model\DictionaryGroupsAdmin and the entity Itfrogs\SiteBundle\Entity\DictionaryGroup remained the same.
Before loading the class does not reach. I checked.
Prompt, where to search?
If any more configs need tell me - I'll post.
Provided you're using the latest Sonata Admin Bundle it should be something like this according to the documentation:
sonata_block:
default_contexts: [cms]
blocks:
sonata.admin.block.admin_list:
contexts: [admin]
If you're using Sonata user bundle with FOSUser bundle then you may not have the right permissions to view your pages.
If you're in fact using FOSUser, Try in command line:
php app/console fos:user:create adminuser --super-admin
You can find more here
**hint: but you must configure the sonata block in your configuration
sonata_block:
default_contexts: [cms]
blocks:
sonata.admin.block.admin_list:
contexts: [admin]
Related
Issue:
I would need to change the basic /camel url which camel uses by default, but when i try to change it in application.yml nothing happens to it.
Would like to keep other systems intact without changing their urls, from what they already have (would require quiet a bit of work in back-end systems)
Current URL: http://localhost:8080/camel/hello
Desired URL: http://localhost:8080/service/hello
Checked links which are NOT working for me:
Link1
Link2
Link3
EG: application.yml
camel:
springboot:
name: CamelRestContext
component:
servlet:
mapping:
enabled: true
context-path: /service
So apparently this way works:
camel:
springboot:
name: RestDSLContext
servlet:
mapping:
context-path: /service/*
rest:
context-path: /service
Is it possible to setup speaking urls in TYPO3 9 for EXT:tx_solr as it was with RealUrl in prev versions?
I've looked at the example of EXT: news and tried to implement the EXT: solr search, but I do not succeed. I tried that:
routeEnhancers:
SearchPlugin:
type: Extbase
limitToPages:
# Suche list view - needed for pagination:
- 36
extension: Solr
plugin: Pi_Search
routes:
- { routePath: '/page/{page}', _controller: 'Search::search', _arguments: {'page': '#widget_0/currentPage'} }
- { routePath: '/list/{page}', _controller: 'News::list', _arguments: {'page': '#widget_0/currentPage'} }
- { routePath: '/tag/{tag_name}', _controller: 'News::list', _arguments: {'tag_name': 'overwriteDemand/tags'}}
- { routePath: '/blog/{news_title}', _controller: 'News::detail', _arguments: {'news_title': 'news'} }
- { routePath: '/archive/{year}/{month}', _controller: 'News::archive' }
defaultController: 'Search::search'
defaults:
page: '0'
requirements:
page: '\d+'
aspects:
page:
type: StaticRangeMapper
start: '1'
end: '100'
EXT:realurl isn't compatible to TYPO3 9.5. Instead with TYPO3 9.5 a new feature called "routing" was established in TYPO3.
You need to add a site configuration to your installation. This can be done via the backend module "Sites".
Afterwards, speaking URLs will work right out of the box for regular pages. If you have any extension installed, you need to add routeEnhancers to your site config.
Documentation:
Site Handling
Page based Routing
Example for routeEnhancers with EXT:news
I'm trying to allow domain users to log into my rundeck instance by following the guide https://vinusumi.wordpress.com/2017/12/28/setup-active-directory-authentication-for-rundeck/. However, I'm running into 2 issues.
For some reason, I'm unable to log into rundeck with a user thats added to the "rundeck_admins" group. I confirmed that the credentials are correct and I believe that the info I added to the "jaas-activedirectory.conf" is syntactically correct and accurate based on my AD settings. According to the "/var/log/rundeck/service.log" it says the following:
2018-12-13 20:13:29.689 DEBUG --- [tp1465511423-25] ailsUsernamePasswordAuthenticationFilter : Updated SecurityContextHolder to contain null Authentication
2018-12-13 20:13:29.689 DEBUG --- [tp1465511423-25] ailsUsernamePasswordAuthenticationFilter : Delegating to
authentication failure handler grails.plugin.springsecurity.web.authentication.AjaxAwareAuthenticationFailureHandler#51aaa9d4
I'm having trouble figuring out the proper syntax regarding the yaml file used for my "rundeck_users" group
description: "Ops Engineers can launch jobs but not edit them"
context:
project: *
for:
resource:
- equals:
kind: 'node'
allow: [read,update,refresh]
- equals:
kind: 'job'
allow: [read,run,kill]
- equals:
kind: 'adhoc'
allow: [read,run,kill]
- equals:
kind: 'event'
allow: [read,create]
job:
- match:
name: '.*'
allow: [read,run,kill]
adhoc:
- match:
name: '.*'
allow: [read,run,kill]
node:
- match:
nodename: '.*'
allow: [read,run,refresh]
by:
group:
- rundeck_users
---
context:
application: rundeck
description: "Ops Engineers can launch jobs but not edit them"
for:
project:
- match:
name: '*'
allow: [read]
system:
- match:
name: '.*'
allow: [read]
by:
group:
- rundeck_users
1.- Make sure the authentication is being read. When rundeck is starting
<..>
2018-12-14 01:52:57.186 INFO --- [ main] rundeckapp.BootStrap : RSS feeds disabled
2018-12-14 01:52:57.187 INFO --- [ main] rundeckapp.BootStrap : Using jaas authentication <<<<<<<<<
<..>
2.- Verify the yaml content is correct for example using http://www.yamllint.com/
3.- Use an existing/working aclpolicy and use your group for testing purpose and check if the acl policy is causing the issue.
Hope it helps
AD authentication - These steps are relevant for rundeck version 3 and up on centos7.
For older rundeck version see procedure I posted here:
https://groups.google.com/forum/#!msg/rundeck-discuss/P2qQHNpDct4/aP0ot7V2BAAJ
Create AD config file with the following content:
AD {
com.dtolabs.rundeck.jetty.jaas.JettyCachingLdapLoginModule required
debug="true"
contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
providerUrl="ldap://<ip>:389 ldap://<ip>:389"
bindDn="CN=authUser,CN=Users,DC=your,DC=domain,DC=com"
bindPassword="<authUserPassword>"
authenticationMethod="simple"
forceBindingLogin="true"
userBaseDn="CN=Users,DC=your,DC=domain,DC=com"
userRdnAttribute="sAMAccountName"
userIdAttribute="sAMAccountName"
userPasswordAttribute="unicodePwd"
userObjectClass="person"
roleBaseDn="CN=Users,DC=your,DC=domain,DC=com"
roleNameAttribute="sAMAccountName"
roleMemberAttribute="member"
roleObjectClass="group"
cacheDurationMillis="300000"
reportStatistics="true";
};
Create file /etc/sysconfig/rundeckd with the following lines.
Note that LOGIN_MODULE value should be the same as what you set in your file.
export JAAS_CONF=/path/to/file/jaas-AD.conf
export LOGIN_MODULE=AD
I recommend creating full control yaml at first so you can test AD authentication, and then remove permissions as necessary. Note groups in yaml should be the same as in your AD.
I might be asking a stupid question but I've spent days on stackoverflow and git as well as Hugo's official documentation and I've gotten 15 different ways of doing something and nothing seems to work.
I have a 1 page hugo website and I want to add in a privacy policy.
Within the root/config.toml I have the following:
[[params.footer.quicklinks]]
text = "Privacy Policy"
link = "privacypolicy.html"
Within root/content I have a file called privacypolicy.md with the following:
---
title: "Privacy Policy"
type: page
page: "privacypolicy.html"
---
Within root/layout/page I have privacypolicy.html
When I click the link on the core page to go to the privacy policy I get a '404 page not found'
Fix the typo layouts. Put the privacypolicy.html file in root/layouts/page dir.
Create a new page dir and put the privacypolicy.md in root/content/page.
Use Url tag in md file like this:
---
title: "your title"
type: page
Url: page/privacypolicy
---
Your content here...
This will open in your http://baseUrl/page/privacypolicy. Recommended to rerun hugo server and hard refresh(ctrl shift R) web pages.
hope someone can steer me in the right direction!
I'm setting up a SonataAdmin based system for a project I'm working on that utilizes the SonataUserBundle.
I have a model setup extending AbstractMain for CRUD actions which is accessible using the navigation menu. From here, as a super admin, I can list, create, edit and delete items. Perfect!
My aim is to use the same SonataAdmin portal for 'subscribed' users, but with limited access. They should only be able to list items. However, I'm at something of a loss when it comes to just how to configure the symfony / sonata / fosuser security & firewall rules going on under the hood to make this happen.
My app/config/security.yml is as such.
security:
role_hierarchy:
ROLE_ADMIN: [ROLE_USER, ROLE_SONATA_ADMIN]
ROLE_SUPER_ADMIN: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]
SONATA:
# - ROLE_SONATA_PAGE_ADMIN_PAGE_EDIT # if you are using acl then this line must be commented
encoders:
FOS\UserBundle\Model\UserInterface: sha512
acl:
provider: mongodb_acl_provider
# https://symfony.com/doc/current/security.html#b-configuring-how-users-are-loaded
providers:
fos_userbundle:
id: fos_user.user_provider.username
hwi:
id: sonata_oauth2_login.user.provider
firewalls:
# disables authentication for assets and the profiler, adapt it according to your needs
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
admin:
# #pattern: /admin(.*) #REMOVE THIS LINE IF YOU ARE USING SONATA ADMIN
context: user
form_login:
provider: fos_userbundle
login_path: /portal/login
use_forward: false
check_path: /portal/login_check
failure_path: null
always_use_default_target_path: false
default_target_path: /portal/dashboard
logout:
path: /portal/logout
target: /portal/login
anonymous: true
oauth:
resource_owners:
google: "/login/check-google"
facebook: "/login/check-facebook"
login_path: /portal/login # For Sonata Admin
use_forward: false
default_target_path: /portal/dashboard # For Sonata Admin
failure_path: /portal/login # For Sonata Admin
oauth_user_provider:
service: sonata_oauth2_login.user.provider
access_control:
# Admin login page needs to be accessed without credential
- { path: ^/portal/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/portal/logout$, role: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/portal/login_check$, role: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/portal/resetting, role: IS_AUTHENTICATED_ANONYMOUSLY }
# Secured part of the site
# This config requires being logged for the whole site and having the admin role for the admin part.
# Change these rules to adapt them to your needs
- { path: ^/portal/, role: [ROLE_ADMIN, ROLE_SONATA_ADMIN, ROLE_SONATA_USER] }
- { path: ^/.*, role: IS_AUTHENTICATED_ANONYMOUSLY }
services:
mongodb_acl_provider:
parent: doctrine_mongodb.odm.security.acl.provider
This is my sonata_admin config under config.yml:
sonata_admin:
title: BLAHBLAH
options:
title_mode: single_text
templates:
list: AppBundle:CRUD:list.html.twig
base_list_field: AppBundle:CRUD:base_list_field.html.twig
layout: AppBundle::standard_layout.html.twig
security:
handler: sonata.admin.security.handler.acl
# handler: sonata.admin.security.handler.role
role_admin: ROLE_ADMIN
role_super_admin: ROLE_SUPER_ADMIN
# acl security information
information:
GUEST: [VIEW, LIST]
STAFF: [EDIT, LIST, CREATE]
EDITOR: [OPERATOR, EXPORT]
ADMIN: [MASTER]
# permissions not related to an object instance and also to be available when objects do not exist
# the DELETE admin permission means the user is allowed to batch delete objects
admin_permissions: [CREATE, LIST, DELETE, UNDELETE, EXPORT, OPERATOR, MASTER]
# permission related to the objects
object_permissions: [VIEW, EDIT, DELETE, UNDELETE, OPERATOR, MASTER, OWNER]
Now, with this configuration, I can (as a superadmin) edit a user and grant the individual user through the ACL settings access to edit their own profile, as seen here:
ACL Settings for user
Nothing exists in the user settings for roles...
Roles for user
I've done what I can to follow along with the SonataUserBundle instructions for setting up security, but I'm falling short in understanding somewhere along the way.
In short, all users will be utilizing the same admin portal. Admins can create new users, products, etc. "Regular" users can edit their own profile and 'view' products from the admin class extended from AbstractAdmin by clicking the link in the menu on the left.
I feel like I'm wandering around Symfony security blindfolded right now with fosuserbundle & sonatauserbundle added to the mix. :(
This is my first post, so please forgive me if I'm missing anything important to include. I'll do my best to fill in any details and I appreciate your time observing my plight!