ComponentSpace

Forums



SAML Cookie SameSite Mode None


SAML Cookie SameSite Mode None

Author
Message
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)

Group: Administrators
Posts: 2.4K, Visits: 6.6K
Chrome SameSite Cookie Change
Chrome version 80, which is scheduled for release in February 2020, includes a change that may impact SAML SSO.

In most versions of the SAML library, a cookie is used to maintain SAML session state in support of the SAML protocol. This cookie must have a SameSite mode of None.

In earlier releases of Chrome, the SameSite mode defaulted to None. The update defaults the SameSite mode to Lax.

Furthermore, if a SameSite mode of None is specified, Chrome requires the Secure attribute to be specified for the cookie.

For more details, please refer to the Background and ASP.NET Support sections below.

Determining the SAML Library Version
The NuGet package manager identifies the product version being used. Alternatively, refer to Determining the Product Version.

What to do if using SAML Library v4.x
No changes are required as SAML library v4.0.0 and above includes inbuilt support for SameSite=None.

If the application targets .NET framework v4.8 or later, the SAML library makes use of the .NET framework's support for SameSite. Otherwise, for earlier releases of the .NET framework, a workaround is employed to add SameSite support.

What to do if using SAML Library v3.x
Prior to v4.7.2, the .NET framework didn't support setting the SameSite mode.

However, SAML library v3.x supports .NET framework versions prior to v4.7.2 and consequently this .NET framework update isn't available.

To avoid the additional disruption of requiring an update to SAML for ASP.NET, a special HTTP module is available that adds the missing SameSite=None.

For example, the HTTP Module updates:


set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; secure; httponly



To:


set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; SameSite=None; secure; httponly



The HTTP module does this using a workaround as SameSite isn't supported by the earlier .NET framework API.

The HTTP module, including full source code, is available for download at:

SAML Cookie HTTP Module

Note that the HTTP module is required even if your application targets .NET framework v4.7.2 or later as the SameSite support isn't included in the SAML library v3.x.

The following steps should be taken:

1. Copy the HTTP Module DLL to the application's bin folder.

2. To enable the HTTP module, update the application's web.config as follows.


<system.webServer>
  <modules>
    <add name="SAMLCookieHttpModule" type="ComponentSpace.SAML2.SAMLCookieHttpModule"/>
  </modules>
</system.webServer>



3. Confirm that SameSite is working as described in the section below.

What to do if using SAML Library releases from v2.5.0 but earlier than v3.0.0
SAML library v2.5.0 introduced the SAML high-level API which uses a cookie to maintain SAML session state.

The ASP.NET session cookie, rather than a separate SAML session cookie, is used to maintain SAML session state.

The ASP.NET session cookie must include a SameSite value of None and should be marked as secure.

To achieve this:

1. Update the web server to the latest ASP.NET release (ie ASP.NET v4.8 or later) to pick up the runtime support for SameSite.

Note that the application may continue to target an earlier version of the .NET framework. For example, your application's project may continue to target .NET framework v4.0 but you need to update the web server to ASP.NET v4.8.

2. Ensure the web server is up to date and the KB article 4531182 and KB article 4524421 updates have been applied. This is also available through KB article 4535104.

Without the updates, the None value does not emit the SameSite cookie header.

For more information, refer to:

https://docs.microsoft.com/en-us/dotnet/api/system.web.configuration.sessionstatesection?view=netframework-4.8

https://docs.microsoft.com/en-us/dotnet/api/system.web.samesitemode?view=netframework-4.8

3. Update the application's web.config to specify the following.


<sessionState cookieSameSite="None" />
<httpCookies requireSSL="true"/>



4. Confirm that SameSite is working as described in the section below.

Without these changes, the SameSite parameter is missing or set to either Lax or Strict.


set-cookie: ASP.NET_SessionId=dwhtw4ajbxblp5pw5arwf0ww; path=/; HttpOnly



After these changes, the SameSite parameter is included.


set-cookie: ASP.NET_SessionId=2s2wesefh0cohv0ugctun4hl; path=/; secure; HttpOnly; SameSite=None



Note though that if the ASP.NET update hasn’t been installed on the web server, the unrecognized cookie SameSite attribute will result in an “Unrecognized attribute” configuration error at runtime.

These changes are not required if calling the SAML low-level API rather than the more commonly used SAML high-level API.

What to do if using SAML Library releases earlier than v2.5.0
SAML library releases prior to v2.5.0 support the SAML low-level API only. The SAML high-level API was introduced in v2.5.0. The SAML low-level API doesn't maintain SAML session state and therefore doesn't use a cookie.

Therefore, no changes are required to use the SAML library releases prior to v2.5.0.

Confirming Correct SameSite Support
It's highly recommended that after making the required changes, the SameSite support is confirmed.

For example, use the Browser developer tools to capture the network traffic.

At the beginning of the SSO flow, there will be a Set-Cookie response header similar to the following.


set-cookie: SAML_SessionId=925a928f-1b6e-469a-9593-3a61d8b0b84d; path=/; SameSite=None; secure; HttpOnly



Ensure the SameSite=None and Secure attributes are present.

Older Browser Support
Some older browsers are incompatible with the SameSite mode of None.

In particular, older releases of Safari, prior to OSX Catalina or iOS 13, will fail if presented with a SameSite mode of None.

It's recommended that users upgrade to the latest OSX or iOS release.

Of course, this may not be possible and the SAML for ASP.NET 4.0.0 and SAML Cookie HTTP Module both include code to detect these older browsers and not include the SameSite mode in the cookie.

There are no known compatibility issues with recent versions of Chrome, Firefox or Edge.

https://www.chromium.org/updates/same-site/incompatible-clients

Background
A SAML session cookie is used to maintain SAML session state and support the SAML protocol.

A set-cookie header may include an optional SameSite attribute whose purpose is to help protect against cross-site request forgery attacks (CSRF).

SAML protocol exchanges are, in most use cases, cross-site. The identity provider (IdP) and service provider (SP) are different sites. Furthermore, these flows do not involve users clicking navigation links from one site to the other. For example, when an IdP sends an SP a SAML response, it returns a 200 HTTP response to the browser containing an HTML form and some JavaScript to automatically submit the form to the SP via an HTTP Post. From the browser's perspective, the current site is the IdP and destination site for the HTTP Post is the SP.

If the SAML session cookie is marked as SameSite=Strict, the browser won't include it with the SAML response as the sites are different. If the SAML session cookie is marked as SameSite=Lax, the browser still won't include it as this isn't considered a top-level navigation action. Specifically, the SameSite specification doesn't consider Post to be a safe HTTP method.

Consequently, the SAML session cookie must be created with a SameSite value of None.

These considerations aren't specific to SAML SSO or ASP.NET. Other external authentication protocols and other platforms potentially have the same issues.

Until recently, Chrome treated a missing SameSite parameter the same as if None had been specified. In other words, None was the default SameSite mode at the browser. Starting with Chrome version 80, SameSite will default to Lax and if a SameSite mode of None is specified, the Secure attribute must be specified for the cookie.

ASP.NET Support
Prior to v4.7.2, the .NET framework didn't support setting the SameSite mode.

For example:
set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; secure; httponly

Microsoft identified this as an issue, given the impending change in browser support.

https://github.com/aspnet/AspNetCore/issues/12125

Updates to the .NET framework are available that ensure a SameSite mode of None is included in the set-cookie header.

https://docs.microsoft.com/en-us/dotnet/api/system.web.httpcookie.samesite?view=netframework-4.8

For example:
set-cookie: SAML_SessionId=4987e404-617c-450c-8515-35d0b0a8f80c; path=/; secure; samesite=none; httponly

References
https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00
https://tools.ietf.org/html/draft-west-cookie-incrementalism-00

https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
https://www.chromestatus.com/feature/5088147346030592
https://www.chromium.org/updates/same-site/incompatible-clients

https://github.com/aspnet/AspNetCore/issues/8212
https://github.com/aspnet/AspNetCore/issues/12125
https://github.com/dotnet/core/blob/master/release-notes/2.2/2.2.8/2.2.8.md

https://docs.microsoft.com/en-us/aspnet/samesite/system-web-samesite
https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/




Regards
ComponentSpace Development
Steve Pont
Steve Pont
New Member
New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)

Group: Forum Members
Posts: 1, Visits: 17
ComponentSpace - 1/4/2020
Chrome SameSite Cookie Change
Chrome version 80, which is scheduled for release in February 2020, includes a change that may impact SAML SSO.

SAML for ASP.NET uses a cookie to maintain SAML session state in support of the SAML protocol. This cookie must have a SameSite mode of None.

In earlier releases of Chrome, the SameSite mode defaulted to None. The update defaults the SameSite mode to Lax.

Furthermore, if a SameSite mode of None is specified, Chrome requires the Secure attribute to be specified for the cookie.

For more details, please refer to the Background and ASP.NET Support sections below.

Determining the SAML for ASP.NET Version
The NuGet package manager identifies the product version being used. Alternatively, refer to Determining the Product Version.

What to do if using SAML for ASP.NET v4.x
No changes are required as SAML for ASP.NET v4.0.0 and above includes inbuilt support for SameSite=None.

If targeting .NET framework v4.8 or later, the .NET framework's support for SameSite is used.

If targeting earlier versions of the .NET framework, a workaround is employed as SameSite isn't supported by the earlier .NET framework API.

What to do if using SAML for ASP.NET v3.x
Prior to v4.7.2, the .NET framework didn't support setting the SameSite mode.

However, SAML for ASP.NET v3.x supports .NET framework versions prior to v4.7.2 and consequently this .NET framework update isn't available.

To avoid the additional disruption of requiring an update to SAML for ASP.NET, a special HTTP module is available that adds the missing SameSite=None.

For example, the HTTP Module updates:


set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; secure; httponly



To:


set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; SameSite=None; secure; httponly



The HTTP module does this using a workaround as SameSite isn't supported by the earlier .NET framework API.

The HTTP module, including full source code, is available for download at:

SAML Cookie HTTP Module

1. Copy the HTTP Module DLL to the application's bin folder.

2. To enable the HTTP module, update the application's web.config as follows.


<system.webServer>
  <modules>
    <add name="SAMLCookieHttpModule" type="ComponentSpace.SAML2.SAMLCookieHttpModule"/>
  </modules>
</system.webServer>



3. Confirm that SameSite is working as described in the section below.

What to do if using SAML for ASP.NET v2.x
SAML for ASP.NET v2.x makes use of the ASP.NET session cookie rather than a separate SAML session cookie to maintain SAML session state.

The ASP.NET session cookie must include a SameSite value of None and should be marked as secure.

To achieve this:

1. Update the web server to the latest ASP.NET release (ie ASP.NET v4.8 or later) to pick up the runtime support for SameSite. The application may continue to target an earlier version of the .NET framework.

2. Update the application's web.config to specify the following.


<sessionState cookieSameSite="None" />
<httpCookies requireSSL="true"/>



3. Confirm that SameSite is working as described in the section below.

Without these changes, the SameSite parameter is missing.


set-cookie: ASP.NET_SessionId=dwhtw4ajbxblp5pw5arwf0ww; path=/; HttpOnly



After these changes, the SameSite parameter is included.


set-cookie: ASP.NET_SessionId=2s2wesefh0cohv0ugctun4hl; path=/; secure; HttpOnly; SameSite=None



Note though that if the ASP.NET update hasn’t been installed on the web server, the unrecognized cookieSameSite attribute will result in an “Unrecognized attribute” configuration error at runtime.

These changes are not required if calling the SAML low-level API rather than the more commonly used SAML high-level API.

Confirming Correct SameSite Support
It's highly recommended that after making the required changes, the SameSite support is confirmed.

For example, use the Browser developer tools to capture the network traffic.

At the beginning of the SSO flow, there will be a Set-Cookie response header similar to the following.


set-cookie: SAML_SessionId=925a928f-1b6e-469a-9593-3a61d8b0b84d; path=/; SameSite=None; secure; HttpOnly



Ensure the SameSite=None and Secure attributes are present.

Older Browser Support
Some older browsers are incompatible with the SameSite mode of None.

In particular, older releases of Safari, prior to OSX Catalina or iOS 13, will fail if presented with a SameSite mode of None.

It's recommended that users upgrade to the latest OSX or iOS release.

Of course, this may not be possible and the SAML for ASP.NET 4.0.0 and SAML Cookie HTTP Module both include code to detect these older browsers and not include the SameSite mode in the cookie.

There are no known compatibility issues with recent versions of Chrome, Firefox or Edge.

https://www.chromium.org/updates/same-site/incompatible-clients

Background
A SAML session cookie is used to maintain SAML session state and support the SAML protocol.

A set-cookie header may include an optional SameSite attribute whose purpose is to help protect against cross-site request forgery attacks (CSRF).

SAML protocol exchanges are, in most use cases, cross-site. The identity provider (IdP) and service provider (SP) are different sites. Furthermore, these flows do not involve users clicking navigation links from one site to the other. For example, when an IdP sends an SP a SAML response, it returns a 200 HTTP response to the browser containing an HTML form and some JavaScript to automatically submit the form to the SP via an HTTP Post. From the browser's perspective, the current site is the IdP and destination site for the HTTP Post is the SP.

If the SAML session cookie is marked as SameSite=Strict, the browser won't include it with the SAML response as the sites are different. If the SAML session cookie is marked as SameSite=Lax, the browser still won't include it as this isn't considered a top-level navigation action. Specifically, the SameSite specification doesn't consider Post to be a safe HTTP method.

Consequently, the SAML session cookie must be created with a SameSite value of None.

These considerations aren't specific to SAML SSO or ASP.NET. Other external authentication protocols and other platforms potentially have the same issues.

Until recently, Chrome treated a missing SameSite parameter the same as if None had been specified. In other words, None was the default SameSite mode at the browser. Starting with Chrome version 80, SameSite will default to Lax and if a SameSite mode of None is specified, the Secure attribute must be specified for the cookie.

ASP.NET Support
Prior to v4.7.2, the .NET framework didn't support setting the SameSite mode.

For example:
set-cookie: SAML_SessionId=59c203d2-8c64-4ac4-b664-6fb8a7320434; path=/; secure; httponly

Microsoft identified this as an issue, given the impending change in browser support.

https://github.com/aspnet/AspNetCore/issues/12125

Updates to the .NET framework are available that ensure a SameSite mode of None is included in the set-cookie header.

https://docs.microsoft.com/en-us/dotnet/api/system.web.httpcookie.samesite?view=netframework-4.8

For example:
set-cookie: SAML_SessionId=4987e404-617c-450c-8515-35d0b0a8f80c; path=/; secure; samesite=none; httponly

References
https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00
https://tools.ietf.org/html/draft-west-cookie-incrementalism-00

https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
https://www.chromestatus.com/feature/5088147346030592

https://github.com/aspnet/AspNetCore/issues/8212
https://github.com/aspnet/AspNetCore/issues/12125
https://github.com/dotnet/core/blob/master/release-notes/2.2/2.2.8/2.2.8.md

https://docs.microsoft.com/en-us/aspnet/samesite/system-web-samesite
https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/


Thanks for providing this information.  I'm a bit confused, however.  We are currently using SAML v2.0 for .NET4 and we are targeting ASP.NET 4.7.2 in our assemblies.  As such, the post says that "No changes are required as SAML for ASP.NET v4.0.0 and above includes inbuilt support for SameSite=None."  So, at first it seems that there's nothing to do and everything is already taken care of.  I then looked at the "Confirming Correct SameSite Support" section and pulled a network trace of the SAML flow and am not seeing a cookie with the "SameSite=None" attribute (or the secure one for that matter).

Could you please clarify steps to take here for my use case of: SAML v2.0 for .NET4 within a project targeting 4.7.2?  Also, should I expect to see "SAML_SessionId" as a specific cookie, or is the name of this cookie customized within the implementation?

We appreciate your feeback.




ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)ComponentSpace Development (3.4K reputation)

Group: Administrators
Posts: 2.4K, Visits: 6.6K
My apologies for the confusion. SAML for ASP.NET v4.x refers to v4.x of the SAML for ASP.NET product rather than ASP.NET v4.x. I've updated the topic to make this clearer by referring to SAML library v4.x etc. Please determine which version of the SAML library you're using. If, for example, it's v3.x then follow the instructions for this version.

For versions from 3.0.0 onward, you should see a cookie named SAML_SessionId. The only exception is if you're calling the SAML low-level API rather than the SAML high-level API.

Let me know if you have any other questions.

Regards
ComponentSpace Development
steve.smith
steve.smith
New Member
New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)

Group: Forum Members
Posts: 3, Visits: 23
Good morning,

Is there some way of checking for sure whether our ComponentSpace SAML based implementation uses cookies? (as I wasn't aware it was).

If I open Chrome, run through a SAML login, and then use the appropriate settings tab to inspect the cookies set for/by our site, I don't see any called "SAML_SessionId".  Does this mean that our implementation is not using cookies, and therefore we're not going to be affected by this change?

I downloaded the current dev preview of Chrome (81.0.4021.2) and also followed the instructions found here - https://www.chromium.org/updates/same-site - to "To test whether your sites may be affected by the SameSite changes", and I can still login to 3rd party sites using SAML SSO.

So I assume in our case, that we don't need to change anything? 

Thanks,

Steve.


prgscd01
prgscd01
New Member
New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)

Group: Forum Members
Posts: 1, Visits: 4
I want to confirm that no changes should be required for Chrome80.  We are currently using ComponentSpace Version 2.2.0.13.  We are also using the low level api.  This was determined after reviewing the documentation which was sent in this email.  (Please see the highlighted, bolded, underline information below).
I’d also like to understand why no changes are necessary when using an older version of ComponentSpace with the low level api.

FROM YOUR DOCUMENATION
What to do if using SAML Library v2.x....

After these changes, the SameSite parameter is included.
 set-cookie: ASP.NET_SessionId=2s2wesefh0cohv0ugctun4hl; path=/; secure; HttpOnly; SameSite=None
 
Note though that if the ASP.NET update hasn’t been installed on the web server, the unrecognized cookieSameSite attribute will result in an “Unrecognized attribute” configuration error at runtime.
These changes are not required if calling the SAML low-level API rather than the more commonly used SAML high-level API.

Confirming Correct SameSite Support
It's highly recommended that after making the required changes, the SameSite support is confirmed.

For example, use the Browser developer tools to capture the network traffic.




aparcelli
aparcelli
New Member
New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)

Group: Forum Members
Posts: 2, Visits: 19
I am slightly confused by the post. We are using SAML v 3.x and are on .Net Framework v 4.7.2. I cannot tell if this affects us or not?
mov3
mov3
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)

Group: Forum Members
Posts: 12, Visits: 60
Has anyone been able to get their saml service provider app to fail on google canary with these issues?
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.
steve.smith
steve.smith
New Member
New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)

Group: Forum Members
Posts: 3, Visits: 23
mov3 - 1/13/2020
Has anyone been able to get their saml service provider app to fail on google canary with these issues?
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.

No - I have tested too, and haven't been able to get a login process to fail. 

I read again, and it seems that the version of the component we're using (2.x) uses the ASP.NET session cookie, and not a custom SAML cookie. 

So far as I can see from research - the changes Google have made only affect cookies that are set via a third party.  e.g. in the scenario that my web page loads some images or videos from a different domain.  The browser will no longer allow cookies to be set for the different domain when a resource has been loaded via (for example) an <img> tag. 

What I can't see is how this affects - in most cases - the SAML login process?  But I could be missing something :) 
mov3
mov3
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)

Group: Forum Members
Posts: 12, Visits: 60
mov3 - 1/13/2020
Has anyone been able to get their saml service provider app to fail on google canary with these issues?
We are confused by the post also. We are using .net 4.5.1 framework and your 3.5 version. We have downloaded google canary which is version 81 and turned on the samesite features in flags but are unable to get our saml service provider application to fail with saml sso with your control. We do see the console warnings but contrary to what they say in google canary 81 the SAML_SessionId cookie is still there and we are unable to find a problem thus far.

The code in the SAmlCookieHttpModule.cs states
/// Recent browser versions now default cookies to SameSite=Lax.
  /// To support SAML SSO, the SAML session cookie must be SameSite=None.

What am I missing?
CBRon
CBRon
New Member
New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)New Member (7 reputation)

Group: Forum Members
Posts: 7, Visits: 41
My test server is Windows Server 2008 R2. It has the latest .Net Framework installed (4.8). We are using ComponentSpace 2.8.50. I added this line to web.config
<sessionState cookieSameSite="None" />

I already had this line
<httpCookies httpOnlyCookies="true" requireSSL="true"/>

Now I get the error
Parser Error Message: Unrecognized attribute 'cookieSameSite'. Note that attribute names are case-sensitive.
What is wrong?


GO


Similar Topics


Execution: 0.000. 4 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Social Logins

Select a Forum....









Forums, Documentation & Knowledge Base - ComponentSpace


Search