diff --git a/docs/Tutorials/Authentication/Inbuilt/Session.md b/docs/Tutorials/Authentication/Inbuilt/Session.md new file mode 100644 index 000000000..809a8a05e --- /dev/null +++ b/docs/Tutorials/Authentication/Inbuilt/Session.md @@ -0,0 +1,59 @@ +# Sessions + +Pode has support for Sessions when using Authentication, by default if you call a Route with authentication and you already have a session on the request then you're "authenticated". If there's no session, then the authentication logic is invoked, and if the details are invalid you're redirected to a login screen. + +If you have a need to use multiple authentication methods for login, and the user can chose the one they want, then on Routes there's no simple way of say which authentication is required. However, under the hood they all create a session object which can be used as a "shared" authentication method. + +This sessions authenticator can be used to pass authentication if a valid session in on the request, or to automatically redirect to a login page if there is no valid session. Useful for if you're using multiple authentication methods the user can choose from. + +## Usage + +To add sessions authentication you can use [`Add-PodeAuthSession`](../../../../Functions/Authentication/Add-PodeAuthSession). The following example will validate a user's credentials on login using Form authentication, but the home page uses session authentication to just verify there's a valid session: + +```powershell +Start-PodeServer { + # endpoint and view engine + Add-PodeEndpoint -Address * -Port 8085 -Protocol Http + Set-PodeViewEngine -Type Pode + + # enable sessions + Enable-PodeSessionMiddleware -Duration 120 -Extend + + # setup form auth for login + New-PodeAuthScheme -Form | Add-PodeAuth -Name 'FormAuth' -FailureUrl '/login' -SuccessUrl '/' -ScriptBlock { + param($username, $password) + + # here you'd check a real user storage, this is just for example + if ($username -eq 'morty' -and $password -eq 'pickle') { + return @{ User = @{ Name = 'Morty' } } + } + + return @{ Message = 'Invalid details supplied' } + } + + # setup session auth for routes and logout + Add-PodeAuthSession -Name 'SessionAuth' -FailureUrl '/login' + + # home page: use session auth, and redirect to login if no valid session + Add-PodeRoute -Method Get -Path '/' -Authentication SessionAuth -ScriptBlock { + Write-PodeViewResponse -Path 'auth-home' + } + + # login page: use form auth here to actually verify the user's credentials + Add-PodeRoute -Method Get -Path '/login' -Authentication FormAuth -Login -ScriptBlock { + Write-PodeViewResponse -Path 'auth-login' -FlashMessages + } + + # login check: again, use form auth + Add-PodeRoute -Method Post -Path '/login' -Authentication FormAuth -Login + + # logout - use session auth here to purge the session + Add-PodeRoute -Method Post -Path '/logout' -Authentication SessionAuth -Logout +} +``` + +### User Object + +If a valid session is found on the request, then the user object set at `$WebEvent.Auth.User` will take the form of which ever authentication method using for login. + +The user object will simply be loaded from the session. diff --git a/docs/Tutorials/Authentication/Overview.md b/docs/Tutorials/Authentication/Overview.md index 1bdd7f62c..a38b3ba7f 100644 --- a/docs/Tutorials/Authentication/Overview.md +++ b/docs/Tutorials/Authentication/Overview.md @@ -164,7 +164,7 @@ The `Auth` object will also contain: | IsAuthenticated | States if the request is for an authenticated user, can be `$true`, `$false` or `$null` | | Store | States whether the authentication is for a session, and will be stored as a cookie | | IsAuthorised | If using [Authorisation](../../Authorisation/Overview), this value will be `$true` or `$false` depending on whether or not the authenticated user is authorised to access the Route. If not using Authorisation this value will just be `$true` | -| Access | If using [Authorisation](../../Authorisation/Overview), this property will contain the access values for the User per Access method. If not using Authorisation this value will just be an empty hashtable | +| Name | The name(s) of the Authentication methods which passed - useful if you're using merged Authentications and you want to know which one(s) passed | The following example get the user's name from the `Auth` object: diff --git a/docs/Tutorials/Authorisation/Overview.md b/docs/Tutorials/Authorisation/Overview.md index 61d80bbd4..fb59aa807 100644 --- a/docs/Tutorials/Authorisation/Overview.md +++ b/docs/Tutorials/Authorisation/Overview.md @@ -2,31 +2,27 @@ Authorisation can either be used in conjunction with [Authentication](../../Authentication/Overview) and [Routes](../../Routes/Overview), or on it's own for custom scenarios. -When used with Authentication, Pode can automatically authorise access to Routes based on Roles; Groups; Scopes; Users; or custom validation logic for you. When authorisation fails Pode will respond with an HTTP 403 status code. +When used with Authentication, Pode can automatically authorise access to Routes based on Roles; Groups; Scopes; Users; or custom validation logic for you, using the currently authenticated User's details. When authorisation fails Pode will respond with an HTTP 403 status code. With authentication, Pode will set the following properties on the `$WebEvent.Auth` object: | Name | Description | | ---- | ----------- | | IsAuthorised | This value will be `$true` or `$false` depending on whether or not the authenticated user is authorised to access the Route | -| Access | This property will contain the access values for the User per Access method | ## Create an Access Method -To validate authorisation in Pode you'll first need to create an Access method using [`Add-PodeAuthAccess`](../../../Functions/Authentication/Add-PodeAuthAccess). At its most simple you'll just need a Name, Type and possibly a Match type. +To validate authorisation in Pode you'll first need to create an Access scheme using [`New-PodeAccessScheme`](../../../Functions/Access/New-PodeAccessScheme), and then an Access method using [`Add-PodeAccess`](../../../Functions/Authentication/Add-PodeAccess). At its most simple you'll just need a Name, Type and possibly a Match type. For example, you can create a simple Access method for any of the inbuilt types as follows: ```powershell -Add-PodeAuthAccess -Name 'RoleExample' -Type Role -Add-PodeAuthAccess -Name 'GroupExample' -Type Group -Add-PodeAuthAccess -Name 'ScopeExample' -Type Scope -Add-PodeAuthAccess -Name 'UserExample' -Type User +New-PodeAccessScheme -Type Role | Add-PodeAccess -Name 'RoleExample' +New-PodeAccessScheme -Type Group | Add-PodeAccess -Name 'GroupExample' +New-PodeAccessScheme -Type Scope | Add-PodeAccess -Name 'ScopeExample' +New-PodeAccessScheme -Type User | Add-PodeAccess -Name 'UserExample' ``` -!!! note - These Types mainly apply when using the Access method with Authentication/Routes. If you're going to be using the Access method in a more adhoc manner via [`Test-PodeAuthAccess`](../../../Functions/Authentication/Test-PodeAuthAccess) then the Type doesn't apply. - ### Match Type Pode supports 3 inbuilt "Match" types for validating access to resources: One, All and None. The default Match type is One; each of them are applied as follows: @@ -40,12 +36,12 @@ Pode supports 3 inbuilt "Match" types for validating access to resources: One, A For example, to setup an Access method where a User must be in every Group that a Route specifies: ```powershell -Add-PodeAuthAccess -Name 'GroupExample' -Type Group -Match All +New-PodeAccessScheme -Type Group | Add-PodeAccess -Name 'GroupExample' -Match All ``` ### User Access Lookup -When using Access methods with Authentication, Pode will lookup the User's "access values" from the `$WebEvent.Auth.User` object. The property within this object that Pode uses depends on the `-Type` supplied to [`Add-PodeAuthAccess`](../../../Functions/Authentication/Add-PodeAuthAccess): +When using Access methods with Authentication and Routes, Pode will lookup the User's "access values" from the `$WebEvent.Auth.User` object. The property within this object that Pode uses depends on the `-Type` supplied to [`New-PodeAccessScheme`](../../../Functions/Access/New-PodeAccessScheme): | Type | Property | | ---- | -------- | @@ -53,21 +49,21 @@ When using Access methods with Authentication, Pode will lookup the User's "acce | Group | Groups | | Scope | Scopes | | User | Username | -| Custom | Custom.[Name] | +| Custom | n/a - you must supply a `-Path` or `-ScriptBlock` to [`New-PodeAccessScheme`](../../../Functions/Access/New-PodeAccessScheme) | You can override this default lookup in one of two ways, by either supplying a custom property `-Path` or a `-ScriptBlock` for more a more advanced lookup (ie: external sources). !!! note - If you're using Access methods in a more adhoc manner via [`Test-PodeAuthAccess`](../../../Functions/Authentication/Test-PodeAuthAccess), the `-Path` property does nothing. However, if you don't supply a `-Source` to this function then the `-ScriptBlock` will be invoked. + If you're using Access methods in a more adhoc manner via [`Test-PodeAccess`](../../../Functions/Authentication/Test-PodeAccess), the `-Path` property does nothing. However, if you don't supply a `-Source` to this function then the `-ScriptBlock` will be invoked. #### Lookup Path -The `-Path` property on [`Add-PodeAuthAccess`](../../../Functions/Authentication/Add-PodeAuthAccess) allows you to specify a custom property path within the `$WebEvent.Auth.User` object, which will be used to retrieve the access values for the User. +The `-Path` property on [`New-PodeAccessScheme`](../../../Functions/Access/New-PodeAccessScheme) allows you to specify a custom property path within the `$WebEvent.Auth.User` object, which will be used to retrieve the access values for the User. For example, if you have Roles for the User set in a `Roles` property within a `Metadata` property, then you'd use: ```powershell -Add-PodeAuthAccess -Name 'RoleExample' -Type Role -Path 'Metadata.Roles' +New-PodeAccessScheme -Type Role -Path 'Metadata.Roles' | Add-PodeAccess -Name 'RoleExample' <# $User = @{ @@ -83,44 +79,48 @@ And Pode will retrieve the appropriate data for you. #### Lookup ScriptBlock -If the source access values you require are not stored in the `$WebEvent.Auth.User` object but else where (ie: external source), then you can supply a `-ScriptBlock` on [`Add-PodeAuthAccess`](../../../Functions/Authentication/Add-PodeAuthAccess). When Pode attempts to retrieve access values for the User, or another Source, this scriptblock will be invoked. +If the source access values you require are not stored in the `$WebEvent.Auth.User` object but else where (ie: external source), then you can supply a `-ScriptBlock` on [`New-PodeAccessScheme`](../../../Functions/Access/New-PodeAccessScheme). When Pode attempts to retrieve access values for the User, or another Source, this scriptblock will be invoked. !!! note - When using this scriptblock with Authentication the currently authenticated User will be supplied as the first parameter, followed by the `-ArgumentList` values. When using the Access methods in a more adhoc manner via [`Test-PodeAuthAccess`](../../../Functions/Authentication/Test-PodeAuthAccess), just the `-ArgumentList` values are supplied. + When using this scriptblock with Authentication the currently authenticated User will be supplied as the first parameter, followed by the `-ArgumentList` values. When using the Access methods in a more adhoc manner via [`Test-PodeAccess`](../../../Functions/Authentication/Test-PodeAccess), just the `-ArgumentList` values are supplied. For example, if the Role values you need to retrieve are stored in some SQL database: ```powershell -Add-PodeAuthAccess -Name 'RoleExample' -Type Role -ScriptBlock { +$scheme = New-PodeAccessScheme -Type Role -ScriptBlock { param($user) return Invoke-Sqlcmd -Query "SELECT Roles FROM UserRoles WHERE Username = '$($user.Username)'" -ServerInstance '(local)' } + +$scheme | Add-PodeAccess -Name 'RoleExample' ``` Or if you need to get the Groups from AD: ```powershell -Add-PodeAuthAccess -Name 'GroupExample' -Type Group -ScriptBlock { +$scheme = New-PodeAccessScheme -Type Group -ScriptBlock { param($user) return Get-ADPrincipalGroupMembership $user.Username | select name } + +$scheme | Add-PodeAccess -Name 'GroupExample' ``` ### Custom Validator -By default Pode will perform basic array contains checks, to see if the Source/Destination access values meet the `-Match` type required. +By default Pode will perform basic array contains checks, to see if the Source/Destination access values meet the `-Match` type required which was set on [`Add-PodeAccess`](../../../Functions/Access/Add-PodeAccess). For example, if the User has just the Role value `Developer`, and Route has `-Role` values of `Developer` and `QA` supplied, and the `-Match` type is left as `One`, then "if the User Role is contained within the Routes Roles" access is authorised. -However, if you require a more custom/advanced validation logic to be applied, you can supply a custom `-Validator` scriptblock to [`Add-PodeAuthAccess`](../../../Functions/Authentication/Add-PodeAuthAccess). The scriptblock will be supplied with the "Source" access values as the first parameter; the "Destination" access values as the second parameter; then followed by the `-ArgumentList` values. This scriptblock should return a boolean value: true if authorisation granted, or false otherwise. +However, if you require a more custom/advanced validation logic to be applied, you can supply a `-ScriptBlock` to [`Add-PodeAccess`](../../../Functions/Authentication/Add-PodeAccess). The scriptblock will be supplied with the "Source" access values as the first parameter; the "Destination" access values as the second parameter; and then followed by the `-ArgumentList` values. This scriptblock should return a boolean value: true if authorisation granted, or false otherwise. !!! note - Supplying a `-Validator` scriptblock will override the `-Match` type supplied, as this scriptblock will be used for validation instead of Pode's inbuilt Match logic. + Supplying a `-ScriptBlock` will override the `-Match` type supplied, as this scriptblock will be used for validation instead of Pode's inbuilt Match logic. For example, if you want to validate that the User's Scopes definitely contains a Route's first Scope value and then at least any 1 of the other Scope values: ```powershell -Add-PodeAuthAccess -Name 'ScopeExample' -Type Scope -ScriptBlock { +New-PodeAccessScheme -Type Scope | Add-PodeAccess -Name 'ScopeExample' -ScriptBlock { param($userScopes, $routeScopes) if ($routeScopes[0] -inotin $userScopes) { @@ -137,25 +137,25 @@ Add-PodeAuthAccess -Name 'ScopeExample' -Type Scope -ScriptBlock { } ``` -## Using with Authentication +## Using with Routes -The Access methods will mostly commonly be used in conjunction with [Authentication](../../Authentication/Overview) and [Routes](../../Routes/Overview). When used together, Pode will automatically validate Route authorisation for you as a part of the Authentication flow. If authorisation fails, an HTTP 403 status code will be returned. +The Access methods will most commonly be used in conjunction with [Authentication](../../Authentication/Overview) and [Routes](../../Routes/Overview). When used together, Pode will automatically validate Route Authorisation for after the Authentication flow. If authorisation fails, an HTTP 403 status code will be returned. -After creating an Access method as outlined above, you can supply the Access method Name to [`Add-PodeAuth`](../../../Functions/Authentication/Add-PodeAuth) using the `-Access` property. +After creating an Access method as outlined above, you can supply the Access method Name to [`Add-PodeRoute`](../../../Functions/Routes/Add-PodeRoute), and other Route functions, using the `-Access` parameter. -On [`Add-PodeRoute`](../../../Functions/Routes/Add-PodeRoute) and [`Add-PodeRouteGroup`](../../../Functions/Routes/Add-PodeRouteGroup) there are the following parameters: `-Role`, `-Group`, `-Scope`, and `-User`. You can supply one ore more string values to these parameters, depending on which Access method type you're using. +On [`Add-PodeRoute`](../../../Functions/Routes/Add-PodeRoute) and [`Add-PodeRouteGroup`](../../../Functions/Routes/Add-PodeRouteGroup) there are also the following parameters: `-Role`, `-Group`, `-Scope`, and `-User`. You can supply one ore more string values to these parameters, depending on which Access method type you're using. -For example, to verify access to a Route to authorise only Developer role accounts: +For example, to verify access to a Route to authorise only Developer role users: ```powershell Start-PodeServer { Add-PodeEndpoint -Address * -Port 8080 -Protocol Http # create a simple role access method - Add-PodeAuthAccess -Name 'RoleExample' -Type Role + New-PodeAccessScheme -Type Role | Add-PodeAccess -Name 'RoleExample' # setup Basic authentication - New-PodeAuthScheme -Basic | Add-PodeAuth -Name 'AuthExample' -Sessionless -Access 'RoleExample' -ScriptBlock { + New-PodeAuthScheme -Basic | Add-PodeAuth -Name 'AuthExample' -Sessionless -ScriptBlock { param($username, $password) # here you'd check a real user storage, this is just for example @@ -173,12 +173,12 @@ Start-PodeServer { } # create a route which only developers can access - Add-PodeRoute -Method Get -Path '/route1' -Role 'Developer' -Authentication 'AuthExample' -ScriptBlock { + Add-PodeRoute -Method Get -Path '/route1' -Role 'Developer' -Authentication 'AuthExample' -Access 'RoleExample' -ScriptBlock { Write-PodeJsonResponse -Value @{ 'Value' = 'Hello!' } } # create a route which only admins can access - Add-PodeRoute -Method Get -Path '/route2' -Role 'Admin' -Authentication 'AuthExample' -ScriptBlock { + Add-PodeRoute -Method Get -Path '/route2' -Role 'Admin' -Authentication 'AuthExample' -Access 'RoleExample' -ScriptBlock { Write-PodeJsonResponse -Value @{ 'Value' = 'Hi!' } } } @@ -198,9 +198,9 @@ Invoke-RestMethod -Uri http://localhost:8080/route2 -Method Get -Headers @{ Auth ## Merging -Similar to Authentication methods, you can also merge Access methods using [`Merge-PodeAuthAccess`](../../../Functions/Authentication/Merge-PodeAuthAccess). This allows you to have an access strategy where multiple authorisations are required to pass for a user to be fully authorised, or just one of several possible methods. +Similar to Authentication methods, you can also merge Access methods using [`Merge-PodeAccess`](../../../Functions/Authentication/Merge-PodeAccess). This allows you to have an access strategy where multiple authorisations are required to pass for a user to be fully authorised, or just one of several possible methods. -When you merge access methods together, it becomes a new access method which you can supply to `-Access` on [`Add-PodeAuth`](../../../Functions/Authentication/Add-PodeAuth). By default the merged access method expects just one to pass, but you can state that you require all to pass via the `-Valid` parameter on [`Merge-PodeAuthAccess`](../../../Functions/Authentication/Merge-PodeAuthAccess). +When you merge access methods together, it becomes a new access method which you can supply to `-Access` on [`Add-PodeRoute`](../../../Functions/Routes/Add-PodeRoute). By default the merged access method expects just one to pass, but you can state that you require all to pass via the `-Valid` parameter on [`Merge-PodeAccess`](../../../Functions/Authentication/Merge-PodeAccess). Using the same example above, we could add Group authorisation to this as well so the Developers have to be in a Software Group, and the Admins in a Operations Group: @@ -209,14 +209,14 @@ Start-PodeServer { Add-PodeEndpoint -Address * -Port 8080 -Protocol Http # create simple role and group access methods - Add-PodeAuthAccess -Name 'RoleExample' -Type Role - Add-PodeAuthAccess -Name 'GroupExample' -Type Group + New-PodeAccessScheme -Type Role | Add-PodeAccess -Name 'RoleExample' + New-PodeAccessScheme -Type Group | Add-PodeAccess -Name 'GroupExample' # setup a merged access - Merge-PodeAuthAccess -Name 'MergedExample' -Access 'RoleExample', 'GroupExample' -Valid All + Merge-PodeAccess -Name 'MergedExample' -Access 'RoleExample', 'GroupExample' -Valid All # setup Basic authentication - New-PodeAuthScheme -Basic | Add-PodeAuth -Name 'AuthExample' -Sessionless -Access 'MergedExample' -ScriptBlock { + New-PodeAuthScheme -Basic | Add-PodeAuth -Name 'AuthExample' -Sessionless -ScriptBlock { param($username, $password) # here you'd check a real user storage, this is just for example @@ -235,12 +235,12 @@ Start-PodeServer { } # create a route which only developers can access - Add-PodeRoute -Method Get -Path '/route1' -Role 'Developer' -Group 'Software' -Authentication 'AuthExample' -ScriptBlock { + Add-PodeRoute -Method Get -Path '/route1' -Role 'Developer' -Group 'Software' -Authentication 'AuthExample' -Access 'MergedExample' -ScriptBlock { Write-PodeJsonResponse -Value @{ 'Value' = 'Hello!' } } # create a route which only admins can access - Add-PodeRoute -Method Get -Path '/route2' -Role 'Admin' -Group 'Operations' -Authentication 'AuthExample' -ScriptBlock { + Add-PodeRoute -Method Get -Path '/route2' -Role 'Admin' -Group 'Operations' -Authentication 'AuthExample' -Access 'MergedExample' -ScriptBlock { Write-PodeJsonResponse -Value @{ 'Value' = 'Hi!' } } } @@ -248,9 +248,9 @@ Start-PodeServer { ## Custom Access -Pode has inbuilt support for Roles, Groups, Scopes, and Users authorisation on Routes. However, if you need to setup a more Custom authorisation policy on Routes you can create an Access method with `-Type` "Custom", and add custom access values to a Route using [`Add-PodeAuthCustomAccess`](../../../Functions/Authentication/Add-PodeAuthCustomAccess). +Pode has inbuilt support for Roles, Groups, Scopes, and Users authorisation on Routes. However, if you need to setup a more Custom authorisation policy on Routes you can create a custom Access scheme by supplying `-Custom` to [`New-PodeAccessScheme`](../../../Functions/Access/New-PodeAccessScheme), and add custom access values to a Route using [`Add-PodeAccessCustom`](../../../Functions/Authentication/Add-PodeAccessCustom). -Custom access values on a User won't be automatically loaded from the User object, and a `-Path` or `-ScriptBlock` on [`Add-PodeAuthAccess`](../../../Functions/Authentication/Add-PodeAuthAccess) will be required. +Custom access values for a User won't be automatically loaded from the authenticated User object, and a `-Path` or `-ScriptBlock` on [`New-PodeAccessScheme`](../../../Functions/Access/New-PodeAccessScheme) will be required. For example, if you wanted to authorise access from a set of user attributes, and based on favourite colour, you could do the following: @@ -259,13 +259,13 @@ Start-PodeServer { Add-PodeEndpoint -Address * -Port 8080 -Protocol Http # create a simple role access method - Add-PodeAuthAccess -Name 'CustomExample' -Type Custom -Path 'Metadata.Attributes' -Validator { + New-PodeAccessScheme -Custom -Path 'Metadata.Attributes' | Add-PodeAccess -Name 'CustomExample' -ScriptBlock { param($userAttrs, $routeAttrs) return ($userAttrs.Colour -ieq $routeAttrs.Colour) } # setup Basic authentication - New-PodeAuthScheme -Basic | Add-PodeAuth -Name 'AuthExample' -Sessionless -Access 'CustomExample' -ScriptBlock { + New-PodeAuthScheme -Basic | Add-PodeAuth -Name 'AuthExample' -Sessionless -ScriptBlock { param($username, $password) # here you'd check a real user storage, this is just for example @@ -288,24 +288,24 @@ Start-PodeServer { } # create a route which only users who like the colour blue can access - Add-PodeRoute -Method Get -Path '/blue' -Authentication 'AuthExample' -ScriptBlock { + Add-PodeRoute -Method Get -Path '/blue' -Authentication 'AuthExample' -Access 'CustomExample' -ScriptBlock { Write-PodeJsonResponse -Value @{ 'Value' = 'Hello!' } } -PassThru | - Add-PodeAuthCustomAccess -Name 'CustomExample' -Value @{ Colour = 'Blue' } + Add-PodeAccessCustom -Name 'CustomExample' -Value @{ Colour = 'Blue' } # create a route which only users who like the colour red can access - Add-PodeRoute -Method Get -Path '/red' -Authentication 'AuthExample' -ScriptBlock { + Add-PodeRoute -Method Get -Path '/red' -Authentication 'AuthExample' -Access 'CustomExample' -ScriptBlock { Write-PodeJsonResponse -Value @{ 'Value' = 'Hi!' } } -PassThru | - Add-PodeAuthCustomAccess -Name 'CustomExample' -Value @{ Colour = 'Red' } + Add-PodeAccessCustom -Name 'CustomExample' -Value @{ Colour = 'Red' } } ``` ## Using Adhoc -It is possible to invoke the Access method validation in an adhoc manner, without (or while) using Authentication, using [`Test-PodeAuthAccess`](../../../Functions/Authentication/Test-PodeAuthAccess). +It is possible to invoke the Access method validation in an adhoc manner, without (or while) using Authentication, using [`Test-PodeAccess`](../../../Functions/Authentication/Test-PodeAccess). -When using the Access methods outside of Authentication/Routes, the `-Type` doesn't really having any bearing. +When using the Access methods outside of Authentication/Routes, the `-Type` doesn't really have any bearing. For example, you could create a Roles Access method and verify some Users Roles within a TCP Verb: @@ -314,14 +314,15 @@ Start-PodeServer { Add-PodeEndpoint -Address * -Port 9000 -Protocol Tcp -CRLFMessageEnd # create a role access method get retrieves roles from a database - Add-PodeAuthAccess -Name 'RoleExample' -Type Role -ScriptBlock { + $scheme = New-PodeAccessScheme -Type Role -ScriptBlock { param($username) return Invoke-Sqlcmd -Query "SELECT Roles FROM UserRoles WHERE Username = '$($username)'" -ServerInstance '(local)' } + $scheme | Add-PodeAccess -Name 'RoleExample' # setup a Verb that only allows Developers Add-PodeVerb -Verb 'EXAMPLE :username' -ScriptBlock { - if (!(Test-PodeAuthAccess -Name 'RoleExample' -Destination 'Developer' -ArgumentList $TcpEvent.Parameters.username)) { + if (!(Test-PodeAccess -Name 'RoleExample' -Destination 'Developer' -ArgumentList $TcpEvent.Parameters.username)) { Write-PodeTcpClient -Message "Forbidden Access" return } @@ -331,4 +332,4 @@ Start-PodeServer { } ``` -The `-ArgumentList`, on [`Test-PodeAuthAccess`](../../../Functions/Authentication/Test-PodeAuthAccess), will supply values as the first set of parameters to the `-ScriptBlock` defined on [`Add-PodeAuthAccess`](../../../Functions/Authentication/Add-PodeAuthAccess). +The `-ArgumentList`, on [`Test-PodeAccess`](../../../Functions/Authentication/Test-PodeAccess), will supply values as the first set of parameters to the `-ScriptBlock` defined on [`New-PodeAccessScheme`](../../../Functions/Access/New-PodeAccessScheme). diff --git a/examples/public/styles/simple.css b/examples/public/styles/simple.css index 7cf2d40c0..22ff031a3 100644 --- a/examples/public/styles/simple.css +++ b/examples/public/styles/simple.css @@ -1,3 +1,11 @@ body { background-color: rebeccapurple; +} + +a { + color: white; +} + +a:visited { + color: yellow; } \ No newline at end of file diff --git a/examples/tcp-server-auth.ps1 b/examples/tcp-server-auth.ps1 index 1678e8c3c..daea3c39e 100644 --- a/examples/tcp-server-auth.ps1 +++ b/examples/tcp-server-auth.ps1 @@ -14,7 +14,7 @@ Start-PodeServer -Threads 2 { New-PodeLoggingMethod -Terminal | Enable-PodeErrorLogging # create a role access method get retrieves roles from a database - Add-PodeAuthAccess -Name 'RoleExample' -Type Role -ScriptBlock { + Add-PodeAccess -Name 'RoleExample' -Type Role -ScriptBlock { param($username) if ($username -ieq 'morty') { return @('Developer') @@ -25,7 +25,7 @@ Start-PodeServer -Threads 2 { # setup a Verb that only allows Developers Add-PodeVerb -Verb 'EXAMPLE :username' -ScriptBlock { - if (!(Test-PodeAuthAccess -Name 'RoleExample' -Destination 'Developer' -ArgumentList $TcpEvent.Parameters.username)) { + if (!(Test-PodeAccess -Name 'RoleExample' -Destination 'Developer' -ArgumentList $TcpEvent.Parameters.username)) { Write-PodeTcpClient -Message "Forbidden Access" 'Forbidden!' | Out-Default return diff --git a/examples/views/auth-about.pode b/examples/views/auth-about.pode new file mode 100644 index 000000000..1df74729c --- /dev/null +++ b/examples/views/auth-about.pode @@ -0,0 +1,23 @@ + +
+