6: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(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "Vojtech Szocs" <vszocs(a)redhat.com>, "Einav Cohen"
<ecohen(a)redhat.com=
, "Itamar Heim" <iheim(a)redhat.com>, "Juan Hernandez"
<jhernand(a)redhat.com>=
, "engine-devel"
<engine-devel(a)ovirt.org>, "Barak Azulay" <bazulay(a)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(a)redhat.com>
>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Vojtech
Szocs" <vszocs@redhat=
.com>, "Einav Cohen"
<ecohen(a)redhat.com>,
>> "Itamar Heim" <iheim(a)redhat.com>, "Juan
Hernandez" <jhernand(a)redhat.co=
m>, "engine-devel"
<engine-devel(a)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--