Sessions resource (Shop API 19.10)

Summary

Http Method Resource Description
POST /sessions

Exchanges a valid JWT into a new session, which is associated with the authenticated or anonymous customer. All Set-Cookie headers for handling the session are applied on the response.

Only the JWT is used to create the new session. Any session IDs included in the request are ignored.

Once you create a session from a JWT, you can use it in parallel with stateless OCAPI calls that use the JWT. There is no need to call the bridging resources again.

If the customer is authenticated and has a storefront basket, that basket is transferred into the session and can be retrieved using BasketMgr.getCurrentBasket(), along with sensitive data such as addresses and payment information. The following examples show why this behavior is important to understand as it relates to guest customers:

Basket created after the session is created:
 POST /customers/auth with type “guest”
 POST /sessions
 POST /baskets
 Storefront request (controller with BasketMgr.getCurrentBasket())
 -> Sensitive data is erased from the basket due to security considerations
 
Basket created before the session is created:
 POST /customers/auth with type “guest”
 POST /baskets
 POST /sessions
 Storefront request (controller with BasketMgr.getCurrentBasket())
 -> Sensitive data is accessible because the basket is marked as secured for this session
 

Exchange JWT

Exchanges a valid JWT into a new session, which is associated with the authenticated or anonymous customer. All Set-Cookie headers for handling the session are applied on the response.

Only the JWT is used to create the new session. Any session IDs included in the request are ignored.

Once you create a session from a JWT, you can use it in parallel with stateless OCAPI calls that use the JWT. There is no need to call the bridging resources again.

If the customer is authenticated and has a storefront basket, that basket is transferred into the session and can be retrieved using BasketMgr.getCurrentBasket(), along with sensitive data such as addresses and payment information. The following examples show why this behavior is important to understand as it relates to guest customers:

Basket created after the session is created:
 POST /customers/auth with type “guest”
 POST /sessions
 POST /baskets
 Storefront request (controller with BasketMgr.getCurrentBasket())
 -> Sensitive data is erased from the basket due to security considerations
 
Basket created before the session is created:
 POST /customers/auth with type “guest”
 POST /baskets
 POST /sessions
 Storefront request (controller with BasketMgr.getCurrentBasket())
 -> Sensitive data is accessible because the basket is marked as secured for this session
 

Url

POST https://hostname:port/dw/shop/v19_10/sessions

Formats

json, xml

Authentication

Name Description
JWT Authentication via Customer JWT token.

Sample

REQUEST:
POST /dw/shop/v19_10/sessions HTTP/1.1
Host: example.com
Authorization: Bearer eyJfdiI6IjXXXXXX.eyJfdiI6IjEiLCJleHAXXXXXXX.-d5wQW4c4O4wt-Zkl7_fiEiALW1XXXX
Content-Length: 0

# in case of success:
 
RESPONSE:
HTTP/1.1 204 NO CONTENT
Set-Cookie : dwsecuretoken_a85a5236a2e852d714eb6f1585efb61c=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT;
Set-Cookie : dwsid=eXv5R3FZGI4BBfbK1Opk5s1mJ-41Aw7ZuaMKxeye5xa16fJMX--AnNkXsvmakbi1UZSzP1zoPmUILgoom1_jKg==;
Set-Cookie : dwanonymous_a85a5236a2e852d714eb6f1585efb61c=bdjalnzmfrkJ0FtYliwud5db67; Max-Age=15552000; 
Cache-Control: max-age=0,no-cache,no-store,must-revalidate

# in case the access token is invalid
 
RESPONSE:
HTTP/1.1 401 UNAUTHORIZED
Expires: Thu, 01-Jan-1970 00:00:00 GMT
Content-Type: application/json;charset=UTF-8
Cache-Control: max-age=0,no-cache,no-store,must-revalidate
{
  "_v":"19.10",
  "_type":"fault",
  "fault":{
    "type":"InvalidAccessTokenException",
    "message":"Unauthorized request. Access token is invalid."
  }
}