Sessions resource (Shop API 23.2)
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:
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
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/v23_2/sessionsFormats
json, xml
Authentication
| Name | Description |
|---|---|
| JWT | Authentication via Customer JWT. |
Sample
REQUEST:
POST /dw/shop/v23_2/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" : "23.2",
"_type":"fault",
"fault":{
"type":"InvalidAccessTokenException",
"message":"Unauthorized request. Access token is invalid."
}
}