H2S5: Access management:


H3S1: Role inheritance:

Hu: All of our access management is done through # AAM Plugin, which we’ve validated # as a high-quality third-party plugin that can solve our needs. A key component of access management is the creation of user roles, or categories, in which individual users, can be assigned. When a role inherits capabilities from a lower | role, this means that, the inheriting role will have all of the capabilities, and more, of the inherited role, and any updates, to the capabilities of the inherited role, including removal of capabilities, will be instantaneously | propagated to the higher | role, except for capabilities, that are separately | defined, for that higher | role. [D]: The role creation menu, within AAM | general, contains a dropdown | menu to select an inherited for the new role.

Martyniuk<a-r>: What is Access Policy? The Access Policy is a well-structured | JSON document that contains one or more statements, params, and dependencies that collectively define access settings to a website’s resources and actions that can be performed upon them. You can find the detailed reference to all supported resources, actions and param on the Access Policy Reference page. In general, a policy may have 3 main sections. All are optional and used depending on the policy | intent. While a policy defines the access rules, there has to be a code that supports it. That is why the majority of policies come with the “Dependency” section that specifies a list of all dependencies that have to be installed. Typically you’ll find dependencies like “WordPress” or “Advanced Access Manager” with the minimum required version. The next important section is “Statement” that contains one or more policy statements with resources that are allowed or denied. Statements can be conditional and are applicable only if defined conditions are met.

H3S2: Log.i-o:

Hu: To create a general log menu item, set a menu item, for all but the home-menus, which can have their unique menus, called 1) log.i-o, and log.i-o, for in users only, will have a 2) URI redirect, from /wp-login.php to /wp-login.php?action=logout. The menu level change will be applied to menu-out only.

H3S3: Menu-out role redirect:

Hu: If the header template part # is merely a container, then a menu can be swapped based on role. Themify<a-r>: Once you activate the plugin, you will see the conditional menus on the Manage Locations tab located in your WP Admin > Appearance > Menus page. 1) To add conditional menu: click “Conditional Menu” and select a menu from the list (you can create these menus in the “Edit Menus” tab)
– You can remove the menu by selecting “Disable Menu” from the list. 2) Click on “+ Conditions” to add conditions in the modal box (tick the checkboxes where you want the menu to appear) 3) To remove the conditional menus, click on the “X” button

Themify’s conditional menu plugin, main editor view.

The problem with this implementation, is its incompleteness; conditional menus does not support the logged in experience, which depends upon a differentiation of roles; without menu-based role redirects, we would need a second | set of pages, for each logged-in | role, and this is obviously untenable, by the principle of scalability. Therefore, AAM plugin should acquire conditional menus, and work with it, in integration with logic, and Site Editor, to add conditional menus based on roles, using the same mechanism, but this should be edited on the AAM plugin general.

H3S4: Known issue: Woo /shop:

Hu: As of 10/22, there is a known | issue with AAM, where the /shop category page for Woo is not restricted. Woo is a separate plugin, and Martyniuk may not have # tested all use cases, as the product pages can be restricted, as posts. In such cases, we can use a “hard | redirect“:

H4S1: URI access rules:

Hu: A URI access rule can be established in AAM through general==>select-role,==>URI access rule; paste the URL that you cannot block with other means, and AAM will complete the re-direct, as normal. However, keep an eye on how many URIs are manually blocked like this, as this is a uni.technical-debt #

When logged out users attempt to access the /shop URL, they will be re-directed to wp-login.php?

H3S5: How to manage WordPress users:

Hu:

H3S6: Role capability inheritance, permanus:

Hu: Using AAM core, you are prompted to establish a parent | role, upon the creation of a new role, but the inheritance of capabilities, in this case, is one | time; future updates to capabilities will not be propagated.

H3S7: Access-Management in p-web:

// add refs:

Hu: Access-management in p-web will be handled at 3 levels:

H4S1: Router-firewall<//ref>:

Hu: This is the highest level, from the prospective of the user-bottom, so the first layer, that an incoming packet will interact with, and the last, that a leaving packet #<Turing>

H4S2: Windows Security inbound rules, firewall<//ref>:

H4S3: Apache<//ref>:

H4S4: Implementation-post: <Github, flare a-r>

1) Highest: Verizon Router at http://192.168.1.1/, password on router. 
	80 / web.server-device port forward: https://192.168.1.1/#/firewall/portforward
	- This rule can be disabled, without being deleted. 

2) Mid: Windows: Windows Security->Advanced Settings->Inbound Rules->New Rule->
	Port->TCP->Specific local port, 80, allow the connection, name "Flare-RTC"
	- This rule can be disabled and re-enabled from the Inbound Rules screen. 
	
3) Lowest: Apache: update C:\wamp64\bin\apache\apache2.4.51\conf\httpd-vhosts.conf:
	Change "Require local" in the localhost to "Require all granted", or by "Require ip [ip-address]"<Apache, a-r>
	Change, also, the desired directory to this same permission within the <Directory> tag. 
	
Out-dated:
	ARP table, Routing table: https://192.168.1.1/#/network/connections/0/edit?from=arptable
	443 / web.server-device port forward: https://192.168.1.1/#/firewall/portforward
	
Docs: 
	4:48 or so: Torogi Pro: https://www.youtube.com/watch?v=gmXwGZK2uZo
	7:00: King HD News: https://www.youtube.com/watch?v=gNC80QdLK48
	H3S5.H4S10-H5S2 and H3S7-H4S1: https://www.wordpress.materialinchess.com/2022/10/30/h2s76-finagling-tcp-ip-architecture-to-enable-true-peer-to-peer-domain-less-information-ex/
	https://www.youtube.com/watch?v=5oen1uL-xpo
	H3S3-H4S8: https://www.wordpress.materialinchess.com/2022/11/12/h2s114-apache-http-servlit-rev/
	https://httpd.apache.org/docs/2.4/howto/access.html
	
Testing: 
	See relevant sections in WP.MIC-H2S74, above. 

H4S5: IP.whitelist-setup:

H5S1:<WP.MIC-H2S74,H3S5.H4S12>: Verizon firewall cannot whitelist.by-IP 12/11/22 H5S2:<WP.MIC-H2S74,H3S7.H4S1-H5S3>: Windows firewall has a scope | feature that needs to be tested 12/11/22 H5S3: Apache has Require ip [ip-address]<WP.MIC-H2S114,H3S3.H4S2-H5S3>that can be used<test-pending>to permit a whitelist | setup.

References:

https://aamplugin.com/article/wordpress-settings-inheritance-with-aam

https://aamplugin.com/article/how-to-manage-wordpress-users

https://aamplugin.com/extension/role-hierarchy

https://aamplugin.com/user-agreement

https://github.com/yakun-hu/flare/blob/main/firewall-settings.txt


Leave a Reply

Your email address will not be published. Required fields are marked *