Spring Boot OAuth2

Traditional deployment

https://projects.spring.io/spring-security-oauth/docs/oauth2.html

Now we will describe the authorization code flow:

POST /oauth/oauth20/token

Returns an OAuth 2.0 token using HTTP POST.

To request an access token using this grant type, the client must have already obtained the Authorization Code from the authorization server. An Authorization Code is a short-lived token issued to the client application by the authorization server upon successful authentication/authorization of an end-user (resource owner). The client application then uses the authorization code to request an access token from the authorization server.

For detailed examples about the types of access tokens supported, with example for each type of access token, refer to OAuth: Client Authentication with the Platform’s OAuth Provider.

Note: there is a corresponding operation that performs the same action using HTTP GET: GET /oauth/oauth20/token. For information on why you might choose one or the other, see OAuth Operations: GET or POST?

Authorization Roles/Permissions: Anyone can run this operation.

This topic includes the following sections:

HTTP Method

POST

Back to top

URL

https://{oauth-provider-url}/oauth/oauth20/token

Back to top

Sample Request

The examples below shows token requests in an LDAP scenario, with several different grant types.

Request URL

https://{oauth-provider-url}/oauth/oauth20/token

Sample request headers

Note: In the sample request headers below, the Authorization header consist of the client’s Basic authentication header, as explained in HTTP Basic Authentication. This is one way of sending the authorization credentials. As an alternative, you can send this information in the POST body or, if you are using the GET operation, in the request parameters. For more information, see OAuth: Client Authentication with the Platform’s OAuth Provider.

POST /oauth/oauth20/token HTTP/1.1
Host: http://{oauth-provider-hostname}
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
Accept: application/json

Sample request body: authorization_code grant type

In the sample request body shown below, the client ID and client secret are included. When the Authorization header is included with the request message, as shown above, you don’t need to send the client ID and client secret in the parameters. Send them either in the header or in the parameters. The below is an example of sending these values in the POST request body if the Authorization header was not sent. Line breaks have been added for display purposes.

client_id=acmepaymentscorp-3rCEQzwEHMT9PPvuXcClpe3v
&client_secret=e5868ebb4445fc2ad9f949956c1cb9ddefa0d421
&code=T8Y2h7zvp-tviqe2gQQ_VGQKMizn8jRgxZ74hA
&redirect_uri=http%3A%2F%2Facmepaymentscorp.com%3A9900%2Fui%2Fapps%2Facmepaymentscorp%2F_VWQJeFH76RyfD6M6FRO5Svg%2Fresources%2Fconsole%2Fglobal%2Foauthclientredirect.html%3Fdynamic%3Dtrue
&grant_type=authorization_code
&scope=Scope1

Sample request body: client_credentials grant type (2-legged)

client_id=acmepaymentscorp-3rCEQzwEHMT9PPvuXcClpe3v
&client_secret=e5868ebb4445fc2ad9f949956c1cb9ddefa0d421
&grant_type=client_credentials
&scope=Scope1

Sample request body: Resource Owner Credentials grant type

client_id=atmosphere-3rCEQzwEHMT9PPvuXcClpe3v
&client_secret=e5868ebb4445fc2ad9f949956c1cb9ddefa0d421
&grant_type=password
&scope=Scope1
&username=eng100
&password=password

Back to top

Request Headers

For general information on request header values, refer to HTTP Request Headers.

HEADER DESCRIPTION
Accept application/json
Content-Type application/x-www-form-urlencoded
Authorization Optional. The Authorization request header authenticates the client with the server.

Back to top

Request Parameters

Note: the parameters below are all standard parameters defined in the OAuth 2.0, OpenID Connect, or JSON Web Token (JWT) specifications.

PARAMETER PARM TYPE DATA TYPE REQUIRED DESCRIPTION
grant_type Form String Required The OAuth grant type.

If the request is a request for a refresh token, the value must be set to refresh_token.

client_id Form String Optional Unique identifier of the client application.

Must be sent; but can be sent as Authorization header.

client_secret Form String Optional The client secret value; this value identifies the client with the provider.

Can be sent as Authorization header. Also, not needed for public client, even if Authorization header is not sent.

refresh_token Form String Optional Refresh Token grant type only: The refresh token.
scope Form String Optional OAuth 2.0: standard scope parameter. One or more scopes configured in the OAuth provider. Space separator for multiple scopes.

The scope of the access request.

code Form String Optional Authorization Code grant type only: The authorization code that was previously received by the client application.
redirect_uri Form String Optional Authorization Code grant type only: The redirect URI of the client application, where it received the authorization code.
username Form String Optional Resource Owner Password Credentials only: The resource owner’s username.
password Form String Optional Resource Owner Password Credentials only: The resource owner’s password.
client_assertion_type Form String Optional JWT Bearer Assertion grant type only:

The format of the assertion as identified by the Authorization Server. The value must be set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer.

client_assertion Form String Optional JWT Bearer Assertion grant type only: The assertion being used to authenticate the client. Only JWT compact serialization is allowed.
assertion Form String Optional JWT Bearer Assertion grant type only: The JWT Bearer Assertion.

Back to top

Response

If successful, this operation returns HTTP status code 200, with the access token.

Back to top

Sample Response

The sample response below shows successful completion of this operation.

Sample response headers: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Sample response body: application/json

Sample response body #1

{
  "access_token": "SlAV32hkKG",
  "token_type": "Bearer",
  "refresh_token": "8xLOxBtZp8",
  "expires_in": 3600,
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
    yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
    NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
    fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
    AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
    Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
    NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
    QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
    K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
    XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
}

Sample response body: authorization_code grant type

{
  "access_token" : "d50d9fd00acf797ac409d5890fcc76669b727e63",
  "token_type" : "Bearer",
  "expires_in" : 1295998,
  "refresh_token" : "TZzj2yvtWlNP6BvG6UC5UKHXY2Ey6eEo80FSYax6Yv8"
}

Sample response body: Client Credentials grant type (2-legged)

{
  "access_token" : "4484e52dc4744374aced826a4543cd28948816ff",
  "token_type" : "Bearer",
  "expires_in" : 1295999
}

Sample response body: Resource Owner Credentials grant type

{
  "access_token" : "49fad390491a5b547d0f782309b6a5b33f7ac087",
  "token_type" : "Bearer",
  "expires_in" : 1295999,
  "refresh_token" : "USrAgmSf5MJ8N_RLQODa7rZ3zNs1Sj1GkSIsTsb4n-Y"
}

Sample response body: Error scenario

Note: in the example below, the state parameter is included in the error response. This would be the case in any scenario where it was included in the request.

{
  error=invalid_request,
  error_description=Unsupported%20response_type%20value,
  state=af0ifjsldkj
}

Back to top

Response Headers

For general information on response header values, refer to HTTP Response Headers.

HEADER DESCRIPTION
Content-Type application/json

Back to top

Response Body: Success

NAME TYPE DESCRIPTION
AccessTokenResponse AccessTokenResponse Contains information about the response to a request for an OAuth Access Token. Used by the token endpoint.

Response Body: Error Scenario

NAME TYPE DESCRIPTION
AccessTokenErrorResponse AccessTokenErrorResponse Contains information about an error response returned by the OAuth Token Endpoint in response to a request for an OAuth 2.0 access token.

Back to top

Error Codes/Messages

If the call is unsuccessful an error code/message is returned. One or more examples of possible errors for this operation are shown below.

ITEM VALUE
500 An error occurred processing the call.

More information about Enterprise API Platform API error messages.

Back to top

Create bootable USB stick from ISO in Mac OS X

Convert the ISO to UDRW format

Mac OS X provides all the tools needed to convert the ISO image to UDRW. The following command will convert the ISO image to the UDRW format.

hdiutil convert -format UDRW -o destination_file.img source_file.iso

You will notice that the destination_file.img from the command will create the file destination_file.img.dmg really. This is because the hdiutil program automatically adds the dmg file extension. This is not a problem as the file extension won’t affect the format of the image.

Prepare the USB stick

Check your USB stick and make a backup if there is any important data on it, as the next steps are going to delete everything on it.

To prepare the USb stick we are going to delete all the partitions on the stick and create an empty partition. To do this we need to know the device name of the USB stick. Open a terminal and execute the following command:

$ diskutil list

You will see a list of disks and partitions. The goal is to identify the USB stick in this output. Depending on your system configuration your output might look different from this one. This appears to show 3 physical discs but it does not. The /dev/disk1 is a virtual disk created because of the partition encryption (FileVault 2) I enabled in Mac OS X.

/dev/disk0
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:      GUID_partition_scheme                        *500.1 GB   disk0
1:                        EFI                         209.7 MB   disk0s1
2:          Apple_CoreStorage                         399.5 GB   disk0s2
3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
5:                 Apple_Boot Boot OS X               134.2 MB   disk0s5
/dev/disk1
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:                  Apple_HFS MacOSX                 *399.2 GB   disk1
/dev/disk2
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:      GUID_partition_scheme                        *2.0 GB     disk2
1:       Microsoft Basic Data UNTITLED 1              2.0 GB     disk2s1

As shown in the output above, the connected USB stick is a small 2.0 GB drive with a FAT partition on it. We are now going to remove this partition in the next step. For the following steps we will need the name of the disk which in this case is “/dev/disk2”.

With the following command the data on the disk (your USB stick) will be deleted!

$ diskutil partitionDisk /dev/disk2 1 "Free Space" "unused" "100%"

With this command the USB stick was re-partitioned to have 1 partition without formatting and 100% of the size of the stick. If you check it again with “diskutil list” you will see the changes already, also the USB stick will no longer be shown in the Finder.

Copy the image to the USB stick

Now we can copy the disk image we created to the USB stick. This is done via the dd(1)command. This command will copy the image to the disk (substitute the appropriate disk name for your USB stick here, as with the re-partitioning command):

$ sudo dd if=destination_file.img.dmg of=/dev/disk2 bs=1m

The dd command does not show any output before it has finished the copy process, so be patient and wait for it to complete.

$ diskutil eject /dev/disk2

To eject the USB stick, use the above command. After this is done, the bootable USB stick is ready to be used.

Original link

GitLab set up ssh key

From local command console type:

cat ~/.ssh/id_rsa.pub

If you see a string starting with ssh-rsa you already have an SSH key pair otherwise you have to generate it.

EX: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQC8PAgJVXMQysVOuI0znKGXaUNqdk4reejNPKlG+/RZ+B47YWmiL/qIFx6ILjLQa8iRMmAj9n3hRGBQoIQnU0ZzickuQ/AJi4cEr2+4Hm6I3QTqodWGOijRBXjhGoToIGAAu1ymM+zNSMMtBvMhaOl8QUFY4dAb6YyZs/gvnWKczw== mac@macs-MacBook-Pro.local

in the user profile add a ssh public key

Don’t paste the private part of the SSH key. Paste the public part, which is usually contained in the file ‘~/.ssh/id_rsa.pub’ and begins with ‘ssh-rsa’

 

Error: modseq_hdr.log_offset too large Centos 7

2018-01-02 01:40:59 imap(info@saic.it): Fatal: master: service(imap): child 18780 killed with signal 6 (core dumps disabled)

2018-01-02 01:40:59 imap(info@saic.it): Error: /var/vmail/saic.it/info/Maildir/dovecot.index: modseq_hdr.log_offset too large

2018-01-02 01:40:59 imap(info@saic.it): Error: /var/vmail/saic.it/info/Maildir/dovecot.index: modseq_hdr.log_offset too large

2018-01-02 01:40:59 imap(info@saic.it): Panic: file mail-transaction-log-file.c: line 1148 (mail_transaction_log_file_get_highest_modseq_at): assertion fa

iled: (offset <= file->sync_offset)

HOW TO SOLVE

find /var/vmail/saic.it/info/Maildir/ -name "dovecot*" -delete

 

Restart Postfix & Dovecot (to rebuild the dovecot files):

$ service dovecot restart
$ service postfix restart

I think the cause is the presence of a virus in some emails attachment.

thanks to this link

IspConfig migration from one server to other.

Usefull link 

You need to backup /var/vmail, /var/www (or the place where you stored the websites), the ispconfig database, all mysql databases of the websites incl. the “mysql” database, the users and passwords in /etc/passwd and /etc/group. Make sure that you backup the directories with preserved permoissions.

We must backup:
c. /var/www (web content)
b. /var/vmail (mail content)
a. /etc/passwd and /etc/group (users)
d. MySQL databases (is it better to stop mysql and tar.gz the /var/lib/mysql?)
e. All /etc/
f. /var/log

MY migration script

#!/bin/bash

#database root password
export username=
export password=
NOW=$(date +”%d-%m-%Y”)

ssh root@IP_OLD rm -rf /root/BACKUP_SERVER/vmail.tar.gz
ssh root@IP_OLD tar -zcvf /root/BACKUP_SERVER/vmail.tar.gz /var/vmail
scp root@IP_OLD:/root/BACKUP_SERVER/vmail.tar.gz ./BACKUP_SERVER/
cd ./BACKUP_SERVER
tar -zxvf vmail.tar.gz
cd ..
rm -rf /var/vmail
mv ./BACKUP_SERVER/var/vmail /var/

ssh root@IP_OLD rm -rf /root/BACKUP_SERVER/www.tar.gz
ssh root@IP_OLD tar -zcvf /root/BACKUP_SERVER/www.tar.gz /var/www
scp root@IP_OLD:/root/BACKUP_SERVER/www.tar.gz ./BACKUP_SERVER/
cd ./BACKUP_SERVER
tar -zxvf www.tar.gz
cd ..
rm -rf /var/www
mv ./BACKUP_SERVER/var/www /var/

ssh root@IP_OLD rm -rf /root/BACKUP_SERVER/log.tar.gz
ssh root@IP_OLD tar -zcvf /root/BACKUP_SERVER/log.tar.gz /var/log
scp root@IP_OLD:/root/BACKUP_SERVER/log.tar.gz ./BACKUP_SERVER/
cd ./BACKUP_SERVER
tar -zxvf log.tar.gz
cd ..
rm -rf /var/log
mv ./BACKUP_SERVER/var/log /var/

ssh root@IP_OLD rm -rf /root/BACKUP_SERVER/opt.tar.gz
ssh root@IP_OLD tar -zcvf /root/BACKUP_SERVER/opt.tar.gz /var/opt
scp root@IP_OLD:/root/BACKUP_SERVER/opt.tar.gz ./BACKUP_SERVER/
cd ./BACKUP_SERVER
tar -zxvf opt.tar.gz
cd ..
rm -rf /var/opt
mv ./BACKUP_SERVER/var/opt /var/

NOW=”03-12-2017″
export NOW

array=(mydb1 mydb2)
for DATABASE in “${array[@]}”
do

export DATABASE

echo “BACKUP MYSQL OF $DATABASE for $NOW”

echo “COPY FILE”
scp root@IP_OLD:/root/BACKUP_SQL/$DATABASE$NOW.sql ./BACKUP_SQL/

echo “DROP DB $DATABASE”
mysql -u $username -p”$password” -e “DROP DATABASE IF EXISTS $DATABASE”

echo “CREATE DB $DATABASE”
mysql -u $username -p”$password” -e “CREATE DATABASE $DATABASE”

echo “RESTORE”
mysql -u $username -p”$password” $DATABASE < ./BACKUP_SQL/$DATABASE$NOW.sql

echo “FINE”
done

export password=”

export PGPASSWORD=”

array=( pgdb1 pgdb2 )

for DATABASE in “${array[@]}”
do

export DATABASE

echo “BACKUP POSTGRES OF $DATABASE for $NOW”

echo “COPY FILE”

scp root@IP_OLD:/root/BACKUP_SQL/$DATABASE$NOW.backup ./BACKUP_SQL/

dropdb –host 127.0.0.1 –port 5432 –username “postgres” –no-password $DATABASE

createdb –host 127.0.0.1 –port 5432 –username “postgres” –no-password $DATABASE

pg_restore –host 127.0.0.1 -U postgres -d $DATABASE –verbose ./BACKUP_SQL/$DATABASE$NOW.backup
done

Increase space Virtual Box and Linux Partition

Clone the disk

VBoxManage clonehd “path/WebServer.vmdk” “path/WebServer.vdi” –format vdi

resize 20*1024 = 20GB

VBoxManage modifyhd “path/WebServer.vdi” –resize 20480

reconvert into vmdk

VBoxManage clonehd “path/WebServer.vdi” “path/WebServer.vmdk” –format vmdk

File -> Virtual Media Manager -> Removed existing images (note, I removed them only from the registry).

1. Open the Oracle VM VirtuaBox Manager
Click on File -> Virtual Media Manager (or Ctrl+D)
2. Delete the hard disk entry in question (select and press “Del” on keyboard)
3. Open “Settings” of the Virtual Machine, go to “Storage”, click “Add Attachment”, select “Add Hard Disk” and “Choose existing disk“, then selected the vdi file and you are done.

  1. Download “gparted-live-x.xx.x-x-ixxx.iso” file from http://gparted.sourceforge.net/download.php. Mount this iso file as CD. Virtual Machine -> Settings -> Storage -> Controller IDE (Right Click) -> Add CD/DVD -> Select gparted-live-x.xx.x-x-ixxx.iso file
  2. Run virtual machine, Virtual Machine will boot from this CD. Choose default values with pressing “Enter”, “Enter” … until Gpart ISO GUI starts. Select tool gpart program and start.
  3. Extend disk size as below;
    • Right click on partitions and if “possible” click on “Disable Active Partion”.
    • Extend Partition as much as possible from GUI (for this case 500GB).
    • Right click the partition which is disabled and select “Enable Active Partion”.
    • Apply and wait until the operations finished.
    • Shut down virtual machine.
    • Unmount gparted-live-x.xx.x-x-ixxx.iso.
      $ Virtual Machine -> Settings -> Storage-> Controller IDE (Right Click on gparted-live-x.xx.x-x-ixxx.iso) -> Remove Attachement
    • Start the virtual machine.

vgdisplay

df -h

File system              Dim. Usati Dispon. Uso% Montato su
/dev/mapper/centos-root   19G  6,2G     13G  34% /
devtmpfs                 910M     0    910M   0% /dev
tmpfs                    920M     0    920M   0% /dev/shm
tmpfs                    920M  8,6M    912M   1% /run
tmpfs                    920M     0    920M   0% /sys/fs/cgroup
/dev/sda1               1014M  188M    827M  19% /boot
tmpfs                    184M     0    184M   0% /run/user/0

 

resize2fs /dev/mapper/centos-root

lvextend -l+100%FREE /dev/mapper/centos-root

resize2fs /dev/mapper/centos-root

xfs_growfs /dev/mapper/centos-root

df -ha

Steps to Perform SSH Login Without Password Using ssh-keygen & ssh-copy-id

ssh-keygen creates the public and private keys. ssh-copy-id copies the local-host’s public key to the remote-host’s authorized_keys file. ssh-copy-id also assigns proper permission to the remote-host’s home, ~/.ssh, and ~/.ssh/authorized_keys.

Step 1: Create public and private keys using ssh-key-gen on local-host

jsmith@local-host$ [Note: You are on local-host here]

jsmith@local-host$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/jsmith/.ssh/id_rsa):[Enter key]
Enter passphrase (empty for no passphrase): [Press enter key]
Enter same passphrase again: [Pess enter key]
Your identification has been saved in /home/jsmith/.ssh/id_rsa.
Your public key has been saved in /home/jsmith/.ssh/id_rsa.pub.
The key fingerprint is:
33:b3:fe:af:95:95:18:11:31:d5:de:96:2f:f2:35:f9 jsmith@local-host

Step 2: Copy the public key to remote-host using ssh-copy-id

jsmith@local-host$ ssh-copy-id -i ~/.ssh/id_rsa.pub remote-host
jsmith@remote-host's password:
Now try logging into the machine, with "ssh 'remote-host'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Note: ssh-copy-id appends the keys to the remote-host’s .ssh/authorized_key.

Step 3: Login to remote-host without entering the password

jsmith@local-host$ ssh remote-host
Last login: Sun Nov 16 17:22:33 2008 from 192.168.1.2
[Note: SSH did not ask for password.]

jsmith@remote-host$ [Note: You are on remote-host here]


The above 3 simple steps should get the job done in most cases.

How to create custom service for Centos 7

Create a script like :

[Unit]

Description = FaradCrmService

After = network.target

[Service]

ExecStart = /var/opt/jdk1.8.0_91/bin/java -jar /root/software/fia/farad-1.5.4.RELEASE.jar

[Install]

WantedBy = multi-user.target

Put the script into -> /usr/lib/systemd/system/farad.service

create a symbolic link like this : ln -s /usr/lib/systemd/system/farad.service /etc/systemd/system/multi-user.target.wants/farad.service

enable the service : systemctl enable farad.service

start the service : service farad start

if modify the script, reload it with : systemctl daemon-reload

check it status : systemctl status farad.service

Apache not start : device: AH01760: failed to create lock (client_lock)

This’s very likely that Apache leaving a bunch of stray semaphore sets
lying around after an attempted restart of apache.

you can use the following commands to check:
#ipcs -s | grep apache

and use the following to kill:
ipcs -s | grep apache | awk ‘ { print $2 } ‘ | xargs -n 1 ipcrm -s

use the username you starts apache (e.g., specified by “User” directive)
instead of ‘apache’ in the commands.

Device: AH01760: failed to create lock (client_lock) – all nonce-count checking, one-time nonces, and MD5-sess algorithm disabled