From the /ServiceModel/AuthService.svc/Login authorization API respond with 4 Set-Cookie headers in the response. But according to the spec [https://datatracker.ietf.org/doc/html/rfc6265#section-4.1] , "Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name."  From the client application, it can't get the all 4 header values, only first one retrievable. Could you please give a fix or suitable workaround for this.

Like 0

Like

2 comments
Best reply

Hi Anusha, 

 

it's now allowed in HTTP/2 (https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.5), which specifies: 

 

8.1.2.5.  Compressing the Cookie Header Field
 
   The Cookie header field [COOKIE] uses a semi-colon (";") to delimit
   cookie-pairs (or "crumbs").  This header field doesn't follow the
   list construction rules in HTTP (see [RFC7230], Section 3.2.2), which
   prevents cookie-pairs from being separated into different name-value
   pairs.  This can significantly reduce compression efficiency as
   individual cookie-pairs are updated.
 
   To allow for better compression efficiency, the Cookie header field
   MAY be split into separate header fields, each with one or more
   cookie-pairs.  If there are multiple Cookie header fields after
   decompression, these MUST be concatenated into a single octet string
   using the two-octet delimiter of 0x3B, 0x20 (the ASCII string "; ")
   before being passed into a non-HTTP/2 context, such as an HTTP/1.1
   connection, or a generic HTTP server application.
 
   Therefore, the following two lists of Cookie header fields are
   semantically equivalent.
 
     cookie: a=b; c=d; e=f
 
     cookie: a=b
     cookie: c=d
     cookie: e=f

Please also check out this article:

 

https://datatracker.ietf.org/doc/html/rfc6265#page-7

 

Best Regards, 

 

Bogdan L.

 

Hi Anusha, 

 

it's now allowed in HTTP/2 (https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.5), which specifies: 

 

8.1.2.5.  Compressing the Cookie Header Field
 
   The Cookie header field [COOKIE] uses a semi-colon (";") to delimit
   cookie-pairs (or "crumbs").  This header field doesn't follow the
   list construction rules in HTTP (see [RFC7230], Section 3.2.2), which
   prevents cookie-pairs from being separated into different name-value
   pairs.  This can significantly reduce compression efficiency as
   individual cookie-pairs are updated.
 
   To allow for better compression efficiency, the Cookie header field
   MAY be split into separate header fields, each with one or more
   cookie-pairs.  If there are multiple Cookie header fields after
   decompression, these MUST be concatenated into a single octet string
   using the two-octet delimiter of 0x3B, 0x20 (the ASCII string "; ")
   before being passed into a non-HTTP/2 context, such as an HTTP/1.1
   connection, or a generic HTTP server application.
 
   Therefore, the following two lists of Cookie header fields are
   semantically equivalent.
 
     cookie: a=b; c=d; e=f
 
     cookie: a=b
     cookie: c=d
     cookie: e=f

Please also check out this article:

 

https://datatracker.ietf.org/doc/html/rfc6265#page-7

 

Best Regards, 

 

Bogdan L.

 

Bogdan Lesyk,

Thanks Bogdan. It was really helpfull, will check alternative way to process from the client API side.

Show all comments

Hello Community!



The Creatio documentation suggests that basic authentication is only available for the OData API and not for a custom configuration web service. Anonymous/Forms authentication are the only 2 ways to authenticate for configuration web services. Would like to reconfirm this.



A typical system integration use case is the following - 

1. Creatio pings an external product/system asking it to do some asynchronous processing. 

2. External product/system pings a Creatio custom configuration call back to inform it regarding the status.

 

Typically, external products only permit registering a callback URL and do not provide for customization to do forms authentication with Creatio. How does one over come this? One way is to make the call back permit anonymous authentication but this is a bad security practice. Is there a way to enable basic authentication for custom configuration services on Creatio?

Like 0

Like

4 comments

Hello! 

 

Custom configuration service becomes available after user authentication via the AuthService.svc. If you don't have a possibility to call it directly from your integration you can create another layer of service from your side to send a response from external product and call auth service and after that configuration web service. 

https://academy.creatio.com/documents/technic-sdk/7-16/creating-configuration-service

 

Best regards, 

Dennis 

Dennis Hudson,

Hi Dennis. We are not in a position to do any customization on the external system side.



Is there anything we can do on Creatio's side to facilitate this?

M Shrikanth,

 

The only way to bypass the Auth service for configuration web services is to create an anonymous web service. As a workaround, you can path login and password to the method in this service and check the validity of credentials in this service using auth service.

Thank you Dennis!

Show all comments