modmellon/auth_mellon_cookie.c

283 lines
7.8 KiB
C
Raw Permalink Normal View History

/*
*
* auth_mellon_cookie.c: an authentication apache module
* Copyright <EFBFBD> 2003-2007 UNINETT (http://www.uninett.no/)
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/
#include "auth_mellon.h"
#ifdef APLOG_USE_MODULE
APLOG_USE_MODULE(auth_mellon);
#endif
/* This function retrieves the name of our cookie.
*
* Parameters:
* request_rec *r The current request. Used to find the identifier of
* the cookie. We also allocate memory from r->pool.
*
* Returns:
* The name of the cookie.
*/
static const char *am_cookie_name(request_rec *r)
{
am_dir_cfg_rec *dir_cfg;
dir_cfg = am_get_dir_cfg(r);
return apr_pstrcat(r->pool, "mellon-", dir_cfg->varname, NULL);
}
/* Calculate the cookie parameters.
*
* Parameters:
* request_rec *r The request we should set the cookie in.
*
* Returns:
* The cookie parameters as a string.
*/
static const char *am_cookie_params(request_rec *r)
{
int secure_cookie;
int http_only_cookie;
const char *cookie_domain = ap_get_server_name(r);
const char *cookie_path = "/";
const char *cookie_samesite = "";
am_dir_cfg_rec *cfg = am_get_dir_cfg(r);
if (cfg->cookie_domain) {
cookie_domain = cfg->cookie_domain;
}
if (cfg->cookie_path) {
cookie_path = cfg->cookie_path;
}
if (cfg->cookie_samesite == am_samesite_lax) {
cookie_samesite = "; SameSite=Lax";
} else if (cfg->cookie_samesite == am_samesite_strict) {
cookie_samesite = "; SameSite=Strict";
}
secure_cookie = cfg->secure;
http_only_cookie = cfg->http_only;
return apr_psprintf(r->pool,
"Version=1; Path=%s; Domain=%s%s%s%s",
cookie_path, cookie_domain,
http_only_cookie ? "; HttpOnly" : "",
secure_cookie ? "; secure" : "",
cookie_samesite);
}
/* This functions finds the value of our cookie.
*
* Parameters:
* request_rec *r The request we should find the cookie in.
*
* Returns:
* The value of the cookie, or NULL if we don't find the cookie.
*/
const char *am_cookie_get(request_rec *r)
{
Add support for SAML ECP. The modifications in this commit address the changes necessary to support the SP component of SAML ECP. The Lasso library needs additional modifications before SAML ECP will be fully functional, those fixes have been submitted to upstream Lasso, mod_auth_mellon will continue to operate correctly without the Lasso upgrade, it just won't properly support ECP without the Lasso fixes. Below are the major logical changes in the commit and the rationale behind them. * Allow compilation against older versions of Lasso by conditionally compiling. Add the following CPP symbols set by configure: * HAVE_ECP * HAVE_LASSO_UTILS_H * Add lasso_compat.h If we can't include lasso utils.h than pull in our own local definitions so we can use some of the valuable utilities. * Add ECP specific documentation file Documentation specific to ECP is now contained in ECP.rst (using reStructuredText formatting). Information on general ECP concepts, mod_auth_mellon user information, and internal mod_auth_mellon coding issues are covered. * Add am_get_boolean_query_parameter() utility * Add am_validate_paos_header() utility This utility routine validates the PAOS HTTP header. It is used in conjunction with am_header_has_media_type() to determine if a client is ECP capable. * Add am_is_paos_request() utility This utility checks to see if the request is PAOS based on the required HTTP header content. * Add utility function am_header_has_media_type() to check if an HTTP Accept header includes a specific media type. This is necessary because the SP detects an ECP client by the presence of a application/vnd.paos+xml media type in the Accept header. Unfortunately neither Apache nor mod_auth_mellon already had a function to check Accept media types so this was custom written and added to mod_auth_mellon. * Add utility function am_get_assertion_consumer_service_by_binding() because Lasso does not expose that in it's public API. It's necessary to get the URL of the PAOS AssertionConsumerService. * Add MellonECPSendIDPList config option This option controls whether to include a list of IDP's when sending an ECP PAOS <AuthnRequest> message to an ECP client. * We need to do some bookkeeping during the processing of a request. Some Apache modules call this "adding a note". mod_auth_mellon was already doing this but because it only needed to track one value (the cookie value) took a shortcut and stuffed the cookie value into the per module request slot rather than defining a struct that could hold a variety of per-request values. To accommodate multiple per request bookkeeping values we define a new struct, am_req_cfg_rec, that holds the previously used cookie value and adds a new ECP specific value. This struct is now the bookkeeping data item attached to each request. To support the new am_req_cfg_rec struct the am_get_req_cfg macro was added (mirrors the existing am_get_srv_cfg, am_get_mod_cfg and am_get_dir_cfg macros). The am_create_request() Apache hook was added to initialize the am_req_cfg_rec at the beginning of the request pipeline. * A new endpoint was added to handle PAOS responses from the ECP client. The endpoint is called "paosResponse" and lives along side of the existing endpoints (e.g. postResponse, artifactResponse, metadata, auth, logout, etc.). The new endpoint is handled by am_handle_paos_reply(). The metadata generation implemented in am_generate_metadata() was augmented to add the paosResponse endpoint and bind it to the SAML2 PAOS binding. * am_handle_reply_common() was being called by am_handle_post_reply() and am_handle_artifact_reply() because replies share a fair amount of common logic. The new am_handle_paos_reply() also needs to utilize the same common logic in am_handle_reply_common() but ECP has slightly different behavior that has to be accounted for. With ECP there is no SP generated cookie because the SP did not initiate the process and has no state to track. Also the RelayState is optional with ECP and is carried in the PAOS header as opposed to an HTTP query/post parameter. The boolean flag is_paos was added as a parameter to am_handle_reply_common() so as to be able to distinguish between the PAOS and non-PAOS logic. * Add PAOS AssertionConsumerService to automatically generated metadata. Note, am_get_assertion_consumer_service_by_binding() should be able to locate this endpoint. * Refactor code to send <AuthnRequest>, now also supports PAOS The creation and initialization of a LassoLogin object is different for the ECP case. We want to share as much common code as possible, the following refactoring was done to achieve that goal. The function am_send_authn_request() was removed and it's logic moved to am_init_authn_request_common(), am_send_login_authn_request() and am_set_authn_request_content(). This allows the logic used to create and initialize a LassoLogin object to be shared between the PAOS and non-PAOS cases. am_send_paos_authn_request() also calls am_init_authn_request_common() and am_set_authn_request_content(). The function am_set_authn_request_content() replaces the logic at the end of am_send_authn_request(), it is responsible for setting the HTTP headers and body content based on the LassoLogin. Signed-off-by: John Dennis <jdennis@redhat.com>
2015-07-06 22:04:55 +02:00
am_req_cfg_rec *req_cfg;
const char *name;
const char *value;
const char *cookie;
char *buffer, *end;
/* don't run for subrequests */
if (r->main) {
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
"cookie_get: Subrequest, so return NULL");
return NULL;
}
/* Check if we have added a note on the current request. */
Add support for SAML ECP. The modifications in this commit address the changes necessary to support the SP component of SAML ECP. The Lasso library needs additional modifications before SAML ECP will be fully functional, those fixes have been submitted to upstream Lasso, mod_auth_mellon will continue to operate correctly without the Lasso upgrade, it just won't properly support ECP without the Lasso fixes. Below are the major logical changes in the commit and the rationale behind them. * Allow compilation against older versions of Lasso by conditionally compiling. Add the following CPP symbols set by configure: * HAVE_ECP * HAVE_LASSO_UTILS_H * Add lasso_compat.h If we can't include lasso utils.h than pull in our own local definitions so we can use some of the valuable utilities. * Add ECP specific documentation file Documentation specific to ECP is now contained in ECP.rst (using reStructuredText formatting). Information on general ECP concepts, mod_auth_mellon user information, and internal mod_auth_mellon coding issues are covered. * Add am_get_boolean_query_parameter() utility * Add am_validate_paos_header() utility This utility routine validates the PAOS HTTP header. It is used in conjunction with am_header_has_media_type() to determine if a client is ECP capable. * Add am_is_paos_request() utility This utility checks to see if the request is PAOS based on the required HTTP header content. * Add utility function am_header_has_media_type() to check if an HTTP Accept header includes a specific media type. This is necessary because the SP detects an ECP client by the presence of a application/vnd.paos+xml media type in the Accept header. Unfortunately neither Apache nor mod_auth_mellon already had a function to check Accept media types so this was custom written and added to mod_auth_mellon. * Add utility function am_get_assertion_consumer_service_by_binding() because Lasso does not expose that in it's public API. It's necessary to get the URL of the PAOS AssertionConsumerService. * Add MellonECPSendIDPList config option This option controls whether to include a list of IDP's when sending an ECP PAOS <AuthnRequest> message to an ECP client. * We need to do some bookkeeping during the processing of a request. Some Apache modules call this "adding a note". mod_auth_mellon was already doing this but because it only needed to track one value (the cookie value) took a shortcut and stuffed the cookie value into the per module request slot rather than defining a struct that could hold a variety of per-request values. To accommodate multiple per request bookkeeping values we define a new struct, am_req_cfg_rec, that holds the previously used cookie value and adds a new ECP specific value. This struct is now the bookkeeping data item attached to each request. To support the new am_req_cfg_rec struct the am_get_req_cfg macro was added (mirrors the existing am_get_srv_cfg, am_get_mod_cfg and am_get_dir_cfg macros). The am_create_request() Apache hook was added to initialize the am_req_cfg_rec at the beginning of the request pipeline. * A new endpoint was added to handle PAOS responses from the ECP client. The endpoint is called "paosResponse" and lives along side of the existing endpoints (e.g. postResponse, artifactResponse, metadata, auth, logout, etc.). The new endpoint is handled by am_handle_paos_reply(). The metadata generation implemented in am_generate_metadata() was augmented to add the paosResponse endpoint and bind it to the SAML2 PAOS binding. * am_handle_reply_common() was being called by am_handle_post_reply() and am_handle_artifact_reply() because replies share a fair amount of common logic. The new am_handle_paos_reply() also needs to utilize the same common logic in am_handle_reply_common() but ECP has slightly different behavior that has to be accounted for. With ECP there is no SP generated cookie because the SP did not initiate the process and has no state to track. Also the RelayState is optional with ECP and is carried in the PAOS header as opposed to an HTTP query/post parameter. The boolean flag is_paos was added as a parameter to am_handle_reply_common() so as to be able to distinguish between the PAOS and non-PAOS logic. * Add PAOS AssertionConsumerService to automatically generated metadata. Note, am_get_assertion_consumer_service_by_binding() should be able to locate this endpoint. * Refactor code to send <AuthnRequest>, now also supports PAOS The creation and initialization of a LassoLogin object is different for the ECP case. We want to share as much common code as possible, the following refactoring was done to achieve that goal. The function am_send_authn_request() was removed and it's logic moved to am_init_authn_request_common(), am_send_login_authn_request() and am_set_authn_request_content(). This allows the logic used to create and initialize a LassoLogin object to be shared between the PAOS and non-PAOS cases. am_send_paos_authn_request() also calls am_init_authn_request_common() and am_set_authn_request_content(). The function am_set_authn_request_content() replaces the logic at the end of am_send_authn_request(), it is responsible for setting the HTTP headers and body content based on the LassoLogin. Signed-off-by: John Dennis <jdennis@redhat.com>
2015-07-06 22:04:55 +02:00
req_cfg = am_get_req_cfg(r);
value = req_cfg->cookie_value;
if(value != NULL) {
return value;
}
name = am_cookie_name(r);
cookie = apr_table_get(r->headers_in, "Cookie");
if(cookie == NULL) {
return NULL;
}
for(value = ap_strstr_c(cookie, name); value != NULL;
value = ap_strstr_c(value + 1, name)) {
if(value != cookie) {
/* value isn't pointing to the start of the string. */
switch(value[-1]) {
/* We allow the name in the cookie-string to be
* preceeded by [\t; ]. Note that only ' ' should be used
* by browsers. We test against the others just to be sure.
*/
case '\t':
case ';':
case ' ':
break;
default:
/* value isn't preceeded by one of the listed characters, and
* therefore we assume that it is part of another cookie.
*/
continue; /* Search for the next instance of the name. */
}
}
if(value[strlen(name)] != '=') {
/* We don't have an equal-sign right after the name. Therefore we
* assume that what we have matched is only part of a longer name.
* We continue searching.
*/
continue;
}
/* Now we have something that matches /[^ ,\t]<name>=/. The value
* (following the equal-sign) can be found at value + strlen(name) + 1.
*/
value += strlen(name) + 1;
/* The cookie value may be double-quoted. */
if(*value == '"') {
value += 1;
}
buffer = apr_pstrdup(r->pool, value);
end = strchr(buffer, '"');
if(end) {
/* Double-quoted string. */
*end = '\0';
}
end = strchr(buffer, ';');
if(end) {
*end = '\0';
}
return buffer;
}
/* We didn't find the cookie. */
return NULL;
}
/* This function sets the value of our cookie.
*
* Parameters:
* request_rec *r The request we should set the cookie in.
* const char *id The value ve should store in the cookie.
*
* Returns:
* Nothing.
*/
void am_cookie_set(request_rec *r, const char *id)
{
Add support for SAML ECP. The modifications in this commit address the changes necessary to support the SP component of SAML ECP. The Lasso library needs additional modifications before SAML ECP will be fully functional, those fixes have been submitted to upstream Lasso, mod_auth_mellon will continue to operate correctly without the Lasso upgrade, it just won't properly support ECP without the Lasso fixes. Below are the major logical changes in the commit and the rationale behind them. * Allow compilation against older versions of Lasso by conditionally compiling. Add the following CPP symbols set by configure: * HAVE_ECP * HAVE_LASSO_UTILS_H * Add lasso_compat.h If we can't include lasso utils.h than pull in our own local definitions so we can use some of the valuable utilities. * Add ECP specific documentation file Documentation specific to ECP is now contained in ECP.rst (using reStructuredText formatting). Information on general ECP concepts, mod_auth_mellon user information, and internal mod_auth_mellon coding issues are covered. * Add am_get_boolean_query_parameter() utility * Add am_validate_paos_header() utility This utility routine validates the PAOS HTTP header. It is used in conjunction with am_header_has_media_type() to determine if a client is ECP capable. * Add am_is_paos_request() utility This utility checks to see if the request is PAOS based on the required HTTP header content. * Add utility function am_header_has_media_type() to check if an HTTP Accept header includes a specific media type. This is necessary because the SP detects an ECP client by the presence of a application/vnd.paos+xml media type in the Accept header. Unfortunately neither Apache nor mod_auth_mellon already had a function to check Accept media types so this was custom written and added to mod_auth_mellon. * Add utility function am_get_assertion_consumer_service_by_binding() because Lasso does not expose that in it's public API. It's necessary to get the URL of the PAOS AssertionConsumerService. * Add MellonECPSendIDPList config option This option controls whether to include a list of IDP's when sending an ECP PAOS <AuthnRequest> message to an ECP client. * We need to do some bookkeeping during the processing of a request. Some Apache modules call this "adding a note". mod_auth_mellon was already doing this but because it only needed to track one value (the cookie value) took a shortcut and stuffed the cookie value into the per module request slot rather than defining a struct that could hold a variety of per-request values. To accommodate multiple per request bookkeeping values we define a new struct, am_req_cfg_rec, that holds the previously used cookie value and adds a new ECP specific value. This struct is now the bookkeeping data item attached to each request. To support the new am_req_cfg_rec struct the am_get_req_cfg macro was added (mirrors the existing am_get_srv_cfg, am_get_mod_cfg and am_get_dir_cfg macros). The am_create_request() Apache hook was added to initialize the am_req_cfg_rec at the beginning of the request pipeline. * A new endpoint was added to handle PAOS responses from the ECP client. The endpoint is called "paosResponse" and lives along side of the existing endpoints (e.g. postResponse, artifactResponse, metadata, auth, logout, etc.). The new endpoint is handled by am_handle_paos_reply(). The metadata generation implemented in am_generate_metadata() was augmented to add the paosResponse endpoint and bind it to the SAML2 PAOS binding. * am_handle_reply_common() was being called by am_handle_post_reply() and am_handle_artifact_reply() because replies share a fair amount of common logic. The new am_handle_paos_reply() also needs to utilize the same common logic in am_handle_reply_common() but ECP has slightly different behavior that has to be accounted for. With ECP there is no SP generated cookie because the SP did not initiate the process and has no state to track. Also the RelayState is optional with ECP and is carried in the PAOS header as opposed to an HTTP query/post parameter. The boolean flag is_paos was added as a parameter to am_handle_reply_common() so as to be able to distinguish between the PAOS and non-PAOS logic. * Add PAOS AssertionConsumerService to automatically generated metadata. Note, am_get_assertion_consumer_service_by_binding() should be able to locate this endpoint. * Refactor code to send <AuthnRequest>, now also supports PAOS The creation and initialization of a LassoLogin object is different for the ECP case. We want to share as much common code as possible, the following refactoring was done to achieve that goal. The function am_send_authn_request() was removed and it's logic moved to am_init_authn_request_common(), am_send_login_authn_request() and am_set_authn_request_content(). This allows the logic used to create and initialize a LassoLogin object to be shared between the PAOS and non-PAOS cases. am_send_paos_authn_request() also calls am_init_authn_request_common() and am_set_authn_request_content(). The function am_set_authn_request_content() replaces the logic at the end of am_send_authn_request(), it is responsible for setting the HTTP headers and body content based on the LassoLogin. Signed-off-by: John Dennis <jdennis@redhat.com>
2015-07-06 22:04:55 +02:00
am_req_cfg_rec *req_cfg;
const char *name;
const char *cookie_params;
char *cookie;
if (id == NULL)
return;
name = am_cookie_name(r);
cookie_params = am_cookie_params(r);
cookie = apr_psprintf(r->pool, "%s=%s; %s", name, id, cookie_params);
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
"cookie_set: %s", cookie);
/* Setting the headers inn err_headers_out ensures that they will be
* sent for all responses.
*/
apr_table_addn(r->err_headers_out, "Set-Cookie", cookie);
/* Add a note on the current request, to allow us to retrieve this
* cookie in the current request.
*/
Add support for SAML ECP. The modifications in this commit address the changes necessary to support the SP component of SAML ECP. The Lasso library needs additional modifications before SAML ECP will be fully functional, those fixes have been submitted to upstream Lasso, mod_auth_mellon will continue to operate correctly without the Lasso upgrade, it just won't properly support ECP without the Lasso fixes. Below are the major logical changes in the commit and the rationale behind them. * Allow compilation against older versions of Lasso by conditionally compiling. Add the following CPP symbols set by configure: * HAVE_ECP * HAVE_LASSO_UTILS_H * Add lasso_compat.h If we can't include lasso utils.h than pull in our own local definitions so we can use some of the valuable utilities. * Add ECP specific documentation file Documentation specific to ECP is now contained in ECP.rst (using reStructuredText formatting). Information on general ECP concepts, mod_auth_mellon user information, and internal mod_auth_mellon coding issues are covered. * Add am_get_boolean_query_parameter() utility * Add am_validate_paos_header() utility This utility routine validates the PAOS HTTP header. It is used in conjunction with am_header_has_media_type() to determine if a client is ECP capable. * Add am_is_paos_request() utility This utility checks to see if the request is PAOS based on the required HTTP header content. * Add utility function am_header_has_media_type() to check if an HTTP Accept header includes a specific media type. This is necessary because the SP detects an ECP client by the presence of a application/vnd.paos+xml media type in the Accept header. Unfortunately neither Apache nor mod_auth_mellon already had a function to check Accept media types so this was custom written and added to mod_auth_mellon. * Add utility function am_get_assertion_consumer_service_by_binding() because Lasso does not expose that in it's public API. It's necessary to get the URL of the PAOS AssertionConsumerService. * Add MellonECPSendIDPList config option This option controls whether to include a list of IDP's when sending an ECP PAOS <AuthnRequest> message to an ECP client. * We need to do some bookkeeping during the processing of a request. Some Apache modules call this "adding a note". mod_auth_mellon was already doing this but because it only needed to track one value (the cookie value) took a shortcut and stuffed the cookie value into the per module request slot rather than defining a struct that could hold a variety of per-request values. To accommodate multiple per request bookkeeping values we define a new struct, am_req_cfg_rec, that holds the previously used cookie value and adds a new ECP specific value. This struct is now the bookkeeping data item attached to each request. To support the new am_req_cfg_rec struct the am_get_req_cfg macro was added (mirrors the existing am_get_srv_cfg, am_get_mod_cfg and am_get_dir_cfg macros). The am_create_request() Apache hook was added to initialize the am_req_cfg_rec at the beginning of the request pipeline. * A new endpoint was added to handle PAOS responses from the ECP client. The endpoint is called "paosResponse" and lives along side of the existing endpoints (e.g. postResponse, artifactResponse, metadata, auth, logout, etc.). The new endpoint is handled by am_handle_paos_reply(). The metadata generation implemented in am_generate_metadata() was augmented to add the paosResponse endpoint and bind it to the SAML2 PAOS binding. * am_handle_reply_common() was being called by am_handle_post_reply() and am_handle_artifact_reply() because replies share a fair amount of common logic. The new am_handle_paos_reply() also needs to utilize the same common logic in am_handle_reply_common() but ECP has slightly different behavior that has to be accounted for. With ECP there is no SP generated cookie because the SP did not initiate the process and has no state to track. Also the RelayState is optional with ECP and is carried in the PAOS header as opposed to an HTTP query/post parameter. The boolean flag is_paos was added as a parameter to am_handle_reply_common() so as to be able to distinguish between the PAOS and non-PAOS logic. * Add PAOS AssertionConsumerService to automatically generated metadata. Note, am_get_assertion_consumer_service_by_binding() should be able to locate this endpoint. * Refactor code to send <AuthnRequest>, now also supports PAOS The creation and initialization of a LassoLogin object is different for the ECP case. We want to share as much common code as possible, the following refactoring was done to achieve that goal. The function am_send_authn_request() was removed and it's logic moved to am_init_authn_request_common(), am_send_login_authn_request() and am_set_authn_request_content(). This allows the logic used to create and initialize a LassoLogin object to be shared between the PAOS and non-PAOS cases. am_send_paos_authn_request() also calls am_init_authn_request_common() and am_set_authn_request_content(). The function am_set_authn_request_content() replaces the logic at the end of am_send_authn_request(), it is responsible for setting the HTTP headers and body content based on the LassoLogin. Signed-off-by: John Dennis <jdennis@redhat.com>
2015-07-06 22:04:55 +02:00
req_cfg = am_get_req_cfg(r);
req_cfg->cookie_value = apr_pstrdup(r->pool, id);
}
/* This function deletes the cookie.
*
* Parameters:
* request_rec *r The request we should clear the cookie in. We will
* allocate any neccesary memory from r->pool.
*
* Returns:
* Nothing.
*/
void am_cookie_delete(request_rec *r)
{
const char *name;
const char *cookie_params;
char *cookie;
name = am_cookie_name(r);
cookie_params = am_cookie_params(r);
/* Format a cookie. To delete a cookie we set the expires-timestamp
* to the past.
*/
cookie = apr_psprintf(r->pool, "%s=NULL;"
" expires=Thu, 01-Jan-1970 00:00:00 GMT;"
" %s",
name, cookie_params);
apr_table_addn(r->err_headers_out, "Set-Cookie", cookie);
}
/* Get string that is used to tie a session to a specific cookie.
*
* request_rec *r The current request.
* Returns:
* The cookie token, as a fixed length byte buffer.
*/
const char *am_cookie_token(request_rec *r)
{
const char *cookie_name = am_cookie_name(r);
const char *cookie_domain = ap_get_server_name(r);
const char *cookie_path = "/";
am_dir_cfg_rec *cfg = am_get_dir_cfg(r);
if (cfg->cookie_domain) {
cookie_domain = cfg->cookie_domain;
}
if (cfg->cookie_path) {
cookie_path = cfg->cookie_path;
}
return apr_psprintf(r->pool, "Name='%s' Domain='%s' Path='%s'",
cookie_name,
cookie_domain,
cookie_path
);
}