14 May
2013
14 May
'13
5:49 p.m.
--=-9LSxtO2jtW2b8wAGRRYW
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Vojtech Szocs p=C3=AD=C5=A1e v =C3=9At 14. 05. 2013 v 10:13 -0400:
> Hi guys,
>=20
> I followed this thread, there are some interesting points, sending my com=
ments below.
>=20
> First of all, I understand that REST API should follow common REST princi=
ples, and implement additional features (such as authentication) seamlessly=
on top of these principles, if possible.
>=20
> It's just that sometimes, especially in JavaScript/HTML world, there are =
known issues (limitations) for which a good REST API implementation should =
provide reasonable workarounds. For me, this means two things:
> (a) issue with browser-specific HTTP 'Authorization' header handling for =
JavaScript apps [https://bugzilla.redhat.com/958861]
> (b) issue with browser-specific cookie handling restriction for JavaScrip=
t apps [*]
> [*] long story short: JavaScript app hosted from "/myapp/index.html" cann=
ot access cookies for say "/api" path, only for "/myapp" path, i.e. cookies=
are under control of browser and not JavaScript app, more details: http://=
en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path
>=20
> Both issues written above have something (very important) in common: "bro=
wser-specific" + browser having control (over 'Authorization' header / cook=
ies) instead of JavaScript app..
>=20
> @Michael: is there some RFE/document for your "URI based authentication" =
proposal? Assuming JSESSIONID could be passed via URI, we could use this as=
a workaround for browser-specific cookie handling restriction. In practice=
, this would mean any JavaScript (WebAdmin itself, UI Plugin, any other web=
app) could talk to REST API without relying on cookies entirely. Even bett=
er, if we could pass auth credentials via URI, we could talk to REST API wi=
thout relying on HTTP 'Authorization' header entirely.
>=20
> Also, I'm not strictly against HTTP Basic Auth used in REST API, I just p=
ointed out some of its drawbacks (a while ago). Originally, I proposed to s=
upport alternative (extra) auth scheme that is better and more secure, but =
in the end, I guess we should settle for one reasonably good auth scheme. I=
looked at SPNEGO [http://en.wikipedia.org/wiki/SPNEGO] - it looks interest=
ing, basically a protocol for negotiating specific auth scheme based on wha=
t server supports, the question is if we really need to support multiple au=
th schemes, or just one that is reasonably good.
Well, there are long-standing RFEs for kerberos support to the portals so i=
t would make sense from that POV.
David
>=20
> One auth scheme I really like is [http://docs.aws.amazon.com/AmazonS3/lat=
est/dev/RESTAuthentication.html] - basically preventing password from being=
sent over the network entirely, which is always a good thing. The disadvan=
tage is that the server has to know password ("secret key") in plain-text f=
or the given user, in order to re-produce & compare signature (hash) of rel=
evant request information. On the other hand, Gerrit REST API uses HTTP Dig=
est Auth [https://gerrit-review.googlesource.com/Documentation/rest-api.htm=
l#_protocol_details] but IMHO Digest Auth is over-complicated protocol, mos=
t importantly its too complex for clients to implement.
>=20
> > and this why we having this discussion, currently options are:
> > 1. adapt session based authentication
> > 2. introduce new concept
>=20
> I'd vote for auth scheme that doesn't contradict general REST principles =
but is reasonably good (easy & secure). One thing is the auth protocol itse=
lf (HTTP Basic Auth), another is how auth-related information is transmitte=
d between client and server (HTTP 'Authorization' header, JSESSIONID cookie=
) - for now I'd just proposed to revisit the "auth-related info transmissio=
n" part..
>=20
> Regards,
> Vojtech
>=20
>=20
> ----- Original Message -----
> From: "Michael Pasternak" <mpastern@redhat.com>
> To: "Alon Bar-Lev" <alonbl@redhat.com>
> Cc: "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com=
>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>=
, "engine-devel" <engine-devel@ovirt.org>, "Barak Azulay" <bazulay@redhat.c=
om>
> Sent: Thursday, May 9, 2013 11:27:35 AM
> Subject: Re: [REST-API] Support passing auth information without having t=
o use HTTP Authorization header #958874
>=20
> On 05/07/2013 07:44 PM, Alon Bar-Lev wrote:
> >=20
> >=20
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern@redhat.com>
> >> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat=
.com>, "Einav Cohen" <ecohen@redhat.com>,
> >> "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.co=
m>, "engine-devel" <engine-devel@ovirt.org>
> >> Sent: Monday, May 6, 2013 9:46:31 AM
> >> Subject: [REST-API] Support passing auth information without having to=
use HTTP Authorization header #958874
> >>
> >>
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=3D958874
> >>
> >> Hi Alon,
> >>
> >> (In reply to comment #2)
> >>>
> >>> Regardless of this specific RFE I would like to write that I don't li=
ke the
> >>> REST API session mechanism
> >>> [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as i=
t
> >>> relays on cookies and not explicit API interaction.
> >>
> >> authentication in RESTful application is a matter of debate, it can be
> >> achieved
> >> in various ways, but session + cookie auth. method is very common and =
usually
> >> effective,
> >>
> >> it's biggest disadvantage is that it's not exactly RESfull cause clien=
t
> >> have to maintain (story) the cookie and not the server (but i wouldn't=
call
> >> it an
> >> issue at all), besides that it's works perfectly well from the REST Po=
V,
> >>
> >> also some may say that cookies are not strong enough and OAuth for ins=
tance
> >> should be used instead, but this is a different story cause in our cas=
e,
> >> cookie
> >> are for the clients (not browsers [1]) that can store them in a secure=
way or
> >> even
> >> not to store at all (in-memory cookie).
> >>
> >> [1] another disadvantage is that webbrowsers not able to access cookie
> >> namespace,
> >> but lately i've suggested URI based authentication [2] to support web
> >> browsers
> >> as well.
> >>
> >> [2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.ht=
ml
> >>
> >> the biggest advantage of the cookie is a session expiration that maint=
ained
> >> by the server and abstracted from the client what is much better from
> >> security
> >> PoV than standard authentication mechanisms such as HTTP basic auth fo=
r
> >> instance
> >> which can be potentially cached.
> >=20
> > Expiration is always managed by server side, regardless the cookie vs t=
icket debate.
> >=20
> >>
> >>> I would have expected a
> >>> 'ticket' to be retrieved and that 'ticket' to be disconnected from th=
e
> >>> application server objects. Although we can refer the 'cookie' as a t=
icket,
> >>> however the requirement to parse it should not be required, there be =
a
> >>> conflict between two separate applications running on same server, an=
d
> >>> there
> >>> may be a problem to transfer credentials between servers.
> >>
> >> well, this is not exactly correct:
> >>
> >> 1. client desn't have to decode/parse the cookie and pass credentials,=
all it
> >> need is
> >> just to store the cookie and pass it as is to server on every reque=
st.
> >=20
> > You just described what cookies are.
> > And if I understand we want better control of application authenticatio=
n, disconnected from 'default browser behavior'.
> >=20
> >> 2. "conflict between two separate applications running on same server"=
?
> >> different cookie
> >> uses different domain & path by spec., can you pls explain what do =
you
> >> mean by this?
> >=20
> > If you call the cookie JSESSIONID....
>=20
> different applications cannot live under same path,
> this what for cookie has a "path" attribute,
>=20
> but it can create a bit of confusion indeed, but you not
> talking with more than one application in same time right ?!,
> i.e container/client fetches the JSESSIONID cookie from the
> specific request/response,
>=20
> so i'm not sure how possibly client can get in reply two
> cookies with a same name (even if all applications are using
> same cookie)
>=20
> > =20
> >>>
> >>> If we modify authentication we should support more authentication typ=
es, at
> >>> least SPNEGO.
> >>>
> >>> In order to allow SPNEGO and other authentication mechanisms, we bett=
er
> >>> force people to use single URI to perform the login and return
> >>> authenticated
> >>> 'ticket' to continue interaction with application.
> >>
> >> this is good for the backend authentication, but is not for the RESTfu=
l
> >> application, it's like buying an aeroplane and driving it on a road,
> >=20
> > And why is that? who are you to decide what authentication mechanism is=
to be used by customers?
>=20
> alon, you misunderstood, i'm not talking about authentication method,
> but about your sentence ^ "we better force people to use single URI"
>=20
> > If customer has a policy of not transmitting passwords over the network=
, then SPENGO is your friend.=20
> > But let's ignore it for now.
>=20
> cookie is not any different from the SPENGO token in this meaning,
> it's just another data container.
>=20
> >=20
> >> "force people to use single URI to perform the login" means SOAP while=
we
> >> wanted REST
> >> where any URI is considered as entry point and actually a resource add=
ress
> >> that should
> >> be accessible/manipulatable and authentication should be
> >> abstracted/disconnected from
> >> this concept.
> >=20
> > Again, you provide statements that are not written in stone.
>=20
> this is main REST principal.
>=20
> > Having custom authentication header breaks the 'plain simple rest'.
> > Having a URI is only makes it easier to manage this breakage.
>=20
> for us, but this is breaks a REST concept.
>=20
> >=20
> >> SPNEGO is only an implementation detail that can be abstracted for the=
API.
> >=20
> > I don't follow.
> >=20
> >>> This will be much simpler
> >>> implementation at the api side and much more efficient, and as we are
> >>> discussion application-to-application interaction there should be no =
user
> >>> experience visible issues.
> >>
> >> i'm not sure: "force people to use single URI to perform the login" an=
d no
> >> "no user experience visible issues."?
> >=20
> > Please describe how the prefer mechanism suggested can be implemented i=
n standard browser.
>=20
> it cannot because authorization header has to be supplied only when
> client wishes to reinitialize the JSESSION, and web browsers can't omit
> it during the lifetime.
>=20
> all this cause we don't support web browsers in api yet, session based
> authentication mechanism was designed for http clients,
>=20
> and this why we having this discussion, currently options are:
>=20
> 1. adapt session based authentication
> 2. introduce new concept
>=20
> personally i prefer #1 as it's less noisy and easily achievable.
>=20
> > And if it cannot, and custom logic is required, why a custom logic that=
accesses a custom URI to perform login is any different.
>=20
> it's not RESTful
>=20
> > =20
> >>>
> >>> What I recommend is purely applicative rest login command...
> >>
> >> IIUC this is SOAP and not REST ...
> >=20
> > Again... please refrain from these kind of void statements.
> > SOAP is a protocol, it has specific format and rules.
> > It may or may not use this or any other suggested authentication mechan=
ism.
>=20
> i'm not talking about the protocol, but about the conceptual differences
> between SOAP and REST services.
>=20
> SOAP is a RPC (Remote Procedure Call) and has single entry point on which
> different methods are invoked, having single dedicated method for login
> works in this case,
>=20
> REST is a ROA (Resource Oriented Architecture), i.e everything is REST is=
a
> resource, and you have to operate on these resources, authentication is o=
nly
> an implementation detail that should not break this concept.
>=20
> now saying this i think is clear that you have no place to put at the log=
in()
> method you've mentioned,
>=20
> standard way for authentication in REST/HTTP is via 'authorization' heade=
r (per request),
> optimizing this we've introduced new concept via sessionid,
>=20
> user can choose between two by passing 'prefer:persistent_auth' header,
>=20
> hope it's clear now, please let me know otherwise.
>=20
> > =20
> >>> ---
> >>> Input: authentication type, authentication credentials
> >>> authentication=3Dhttp
> >>> authentication=3Dpassword
> >>> credentials:
> >>> user=3Duser
> >>> password=3Dpassword
> >>> [OPTIONALLY] HTTP authentication headers
> >>> Output:
> >>> ticket
> >>> ticket issue time (required to avoid clock sync)
> >>> ticket expiration time
> >>> Logic:
> >>> if authentication is http, use http authentication headers to establi=
sh
> >>> user
> >>> authentication. This will allow future SSO.
> >>> if authentication is password, use embedded credentials.
> >>> ---
> >>>
> >>> For every other rest call add http header:
> >>> oVirt-Authentication-Ticket: <ticket>
> >>
> >> this is not any different from the today's session based auth. only
> >> instead of oVirt-Authentication-Ticket added cookie.
> >=20
> > I did not claim otherwise, I wrote that I don't like cookies, I do like=
explicit headers.
> > As I wrote, cookies has limited storage at client, cookies may conflict=
, cookies has issues with clusters.
> > Headers do not.
>=20
> using headers has own drawbacks, WebAdmin core is not only entity that
> requires authentication in the app, i'll give you one use-case:
>=20
> today we have plugin interface in WebAdmin, WebAdmin may have different
> plugins installed, to maintain different permissions for every plugin,
> each will have to send own authorization data on every request,
>=20
> as you see this turns to be truly complex, almost not feasible via header=
s,
>=20
> btw in other thread i suggested to used URL parameters for passing authen=
tication
> tokens.
>=20
> >=20
> >>>
> >>> The backend side will attach the correct security context to the acti=
on if
> >>> the header is received.
> >>
> >> this is how it's works today.
> >=20
> > I could not imagine that.
> > =20
> >=20
> > Regards,
> > Alon
> >=20
>=20
>=20
--=20
David Ja=C5=A1a, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24=20
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
--=-9LSxtO2jtW2b8wAGRRYW
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMdTCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGg
AwIBAgIDBl1jMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTMwNDEwMTE0ODI4WhcNMTQwNDEwMTM1MDM0WjBXMRkwFwYDVQQNExAxUktWVnliSEdDZnRMWjY3
MRkwFwYDVQQDDBBkamFzYUByZWRoYXQuY29tMR8wHQYJKoZIhvcNAQkBFhBkamFzYUByZWRoYXQu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx8unM64NLnlRZujXHb0ilCaqc7KB
r1MwlyCtOWAyH4M/24zvfyRQyTz4ZkHd1sMeewJ5ap1/128hLSqMY/6So5yhL6UlK3nM1r9H9PTz
CiPEMZmDazIzMb/Mt/4N3kkJBLpWPFRB5aB+COcex7a4dlmnUJASVWkVwvHRmfa06anME7DTccV5
cV95FKqoRUXawopdu5W2NhailCtbQJAbMIGf9FpH+J98swAsVHdvjZkSDnZcoQIPHzoPrEBawb7C
vsmCe8p7pv5Dxtx3T47FdAXJiO9u+QJkaBFjfiA9ywN8fFo3Q/Jr4vl6WqEr1SyQjgL9/dWeQSYI
8LzByChnXQIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYI
KwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ5AqZ3fyU5HOme+iF4KA3f8RxHPjAfBgNVHSME
GDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBkamFzYUByZWRoYXQuY29tMIIB
TAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQg
YWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBT
dGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3Nl
IGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQv
MC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF
BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx
L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3Vi
LmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t
LzANBgkqhkiG9w0BAQUFAAOCAQEArlvH1bAdnpLvyeMQzPtJYs65ur7cpYnrxrIZ3P/r0F7juzIU
fb1S+M9sYBhalmBoZQMySlVveDYHUHPDsNJQtqUzYAJMbVTdRtviCSq3wmYtG/VJOOif11gM25u4
HcgXVuhF3di5G0CHwAIx0mjUi7fPJ3WMeFKWp550ZqpbFK/i9A5fJGfHk3MfXOhAu7vkEEjJY+gA
BpFqvk134+30mP4KoXfNGZpekWvj6lS/tfaxuuSTusPcY0yIGGtJqqFtL1tRlTIoaDGiok5O0k6W
pMFPtm+dGnOyKT4HQMFCaAgBOVCQFDYthuGlnUlJOP/BheuvaMfwgIqM4ir+DIqOyjGCAhswggIX
AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwZdYzAJBgUrDgMCGgUAoF0wGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTE0MTU0OTIwWjAjBgkq
hkiG9w0BCQQxFgQUeUMi45pkz/QGd6S5e8lzrdExJkQwDQYJKoZIhvcNAQEBBQAEggEAsm2Mob5X
TUMBNhTnxbzYlyJ8kyQq43SsauAqDo+J0hzrtjEdyR5IQerV3LQStJTNgkJ6nphBW7IjBqbGyAF4
ZHABHygBkqj49qo2tub1Z3LcGrHPKM4gsTb5yCHKM2u52PO+PZh3hoF27PVyBsqoEct3uPkOtFmd
GeiM+ZKtl1a38s0ssnP/CuCbhjqPUQEwY3Xg/tWSWiIWCxzyh+tL5/AIdFCDag0bttFdqZ1NjmhF
7I6pbkP5FKwYh4blD2rqa7SHVyFjXx5HTo/kY1kRGuPdbW3inPK9y/3y+Y1Q8qNOKVyYkvGhJRXO
GmVV8rTH5U/UFGzRkPoOYxdlDy+wOAAAAAAAAA==
--=-9LSxtO2jtW2b8wAGRRYW--