Tip:
Highlight text to annotate it
X
DAN HERMES: Hey, everyone.
So for those who don't know, my name is Dan Hermes.
I'm part of Developer Relations here at Google.
I support the Content API for Shopping as well as the Search
API for Shopping, and I'm a member of a larger team that
supports all the Commerce APIs here at Google.
Today, May 16, we're here to talk about the
Content API for Shopping.
We don't have any sort of agenda, but based on the faces
and names I see, I'm sure we'll have
plenty to chat about.
Like I said before, if there is an issue of with reverb of
my voice, let me know and I can deal with that.
So before I open up the floor for questions, I have some
questions for you guys, namely one question that could lead
to some discussion.
And I was sharing with my team this week, and thinking of
ways we can slice this biweekly event up.
And I was just wondering if were any particular types of
people that you guys would like to see in this Hangout,
like the engineers that work on the API, if they could come
in and be guest stars once in a while.
Or maybe if there's Sales, or maybe if there's people from
Ops, like we had four weeks ago at the Hangout before
last. So any suggestions from the floor?
MALE SPEAKER: [UNINTELLIGIBLE]
here.
DAN HERMES: How you doing?
MALE SPEAKER: Hi.
What about the team that does the exceptions?
DAN HERMES: OK.
I know what you're saying.
So you mean exceptions--
something we discussed at a previous Hangout, for those
who didn't see it, exceptions or acceptances for accounts
and things like that, yeah?
MALE SPEAKER: Yeah.
That's correct.
DAN HERMES: OK.
Yeah, that's something I can look into.
I don't have that strong a relationship with those folks,
but I can definitely check it out.
It certainly would be helpful to have some preset questions
before we have a guest like that show up, but
I'll look into it.
Anything else?
CAROLINE: Danny, is that the same as the
data quality folks?
DAN HERMES: The data quality folks, it's a pretty
distributed team.
There are engineering folks.
There's the support part of that.
I'd be happy to get either one.
I actually quite like the engineering folks who work on
that there.
It's a big team in Zurich, and also the API team for this API
in particular is also in Zurich.
But that's something we'd look into.
I know you were wanting more parity between what you get
from the data quality feed and what you see in the merchant
center, and that's something our direct engineers would
have an impact on.
Is there something else you were thinking of when
requesting those folks?
CAROLINE: Yeah, actually, it just seems to me, the one
meeting I attended, there was probably two or three
different times where you said I'm not the data quality, so I
can't really answer that question with authority.
So it just seems like a lot of those questions come up, and I
think they would benefit me even if I
don't have the question.
That data quality is definitely one of the more
complicated and concerning pieces of that.
DAN HERMES: Yeah, that's a great point.
Maybe we could just have like an out of band.
Rather than a biweekly hanging out, we could have a dedicated
Q&A mixed with a bit of lecturing on data quality.
But that's a great suggestion.
ANDREW: I--
DAN HERMES: Andrew, you look like you're about to talk?
ANDREW: Yeah.
Can you guys hear me?
DAN HERMES: Yeah.
ANDREW: OK.
I'm not sure about a specific guest request, but I would be
interested in hearing about new features, what you guys
are working on.
I mean, I don't know how much you guys like to talk about
that sort of stuff, but if you have
project managers or something.
Even if it's just for things like the Merchant Center, or
new graphs, or feedback, or whatever.
DAN HERMES: Yeah, we do have a PM.
I will sync up with those folks and see how much they're
willing to reveal.
The thing about doing something like that is, unless
it's pretty close to production, it's sort of
you're making false promises sometimes.
Because sometimes, something will be halfway along and get
de-prioritized.
And even though it'll only take a couple weeks of work,
there's nobody working on it for those couple of weeks, and
things like that.
But I'll certainly look into it and ask the PM what he
thinks about coming to this.
There are two different PMs involved with Content API,
both of whom are pretty interesting dudes.
So I will add them to the list of requested guests.
Anything else?
ANDREW: Another thing that I don't know how many other
people in this Hangout have experience with this.
But another thing that we do is we use our content feeds
for AdWords and other--
like Google Affiliate Network and places like that.
It might be kind of cool to have one of those guys in at
some point to talk about what they're doing with the feeds,
what they like, what kind of metadata they care about.
Because I know it's sort of different than what is used in
the Google Shopping Experience.
DAN HERMES: Right, right.
There is a wealth of other attributes that you can send,
as Andrew knows.
And Andrew has probably sent just about every possible
attribute you could send that teams at Google are parsing in
one way or another.
And I can certainly look into getting those people on, or if
not getting them on, possibly getting some sort of interview
that I could play for everyone with them about those things.
Because like Andrew said, there are a lot of extra
things you can do with targeting and enable some of
that within your feeds.
That's great.
So now, let's open the floor back up like we usually do.
There were no specific questions, again, this time,
but two weeks ago, we didn't have any specific questions
and still went 45 minutes.
So I think we'll be all right.
So I'd say the first questions we should jump on are the
OAuth 2.0 questions that have been bouncing around with Luke
and Caroline.
So if you guys want to ask those or give a recap, and
then we can jump in.
LUKE: Well, the old client login is going to depreciate
in three years, right?
So this is not--
DAN HERMES: Yes, it's deprecating in three years.
Client login, AuthSub, and OAuth 1.0 are three of, I
believe, the only four methods Google supports for
authentication, but I don't know.
There might be more than the four.
But it was announced about a month ago that those three
methods will be deprecated over a three-year period.
So you're right.
It's not that urgent.
But given the fact that it will be going away, especially
for you, Luke, as you're building a user base and
you're not really at critical mass yet, the more users you
have on something, the harder it is to switch, right?
LUKE: I'm server-to-server, so I have to use the JWT
server-to-server pattern, right?
DAN HERMES: Not necessarily.
If you're just using your MCA, you can get a refresh and an
access token one time, and you can do that server-side.
There's a special redirect URI that isn't actually a website.
It's like OOB colon.
It's a colon-delimited string of six things.
And you can do that one time, get your refresh token and
your access token just for your account, your MCA that's
making all the requests, and you can go server-to-server
all you want.
I'm not entirely sure what the server-to-server stuff that
Caroline was hoping to get out of that.
But for you, if you don't actually need refresh and
access tokens from every user, if you're just creating
sub-accounts with your MCA for each of your users, you only
need one refresh token.
And as long as you on your account never revoke that
refresh token, you can use it ad infinitum to get a new
access token every time another access token expires.
And then from there, if you find a way--
I was just reading about this.
There's no preset way to serialize the data with the
DotNet Client Library, but there is
with every other library.
But there are public attributes.
There are public getters and setters for
everything you want.
So before you kill your process, if you save those
tokens somewhere safe and secure, then you could start a
process back up, reinstantiate an OAuth 2.0 parameters class,
at least in the DotNet case, and then just use the setters
to set that refresh token.
Then everything else happens under the covers when code
snippet but that's been bouncing around the forums for
DotNet, and with every client library, that is, if you set
up your request factory or your service or your client
object, whatever the local term is for it, or whatever is
doing the work of making and sending the request, if you
set it up with an OAuth 2.0 token, it handles everything
else under the covers.
As long as you have a refresh token, you don't have
to worry about it.
Because what the client will do, it'll try to make a
request. If it succeeds, it succeeds.
If it fails, then it'll get a 401 back, which means
unauthorized.
It knows it's unauthorized, so then it tries to make a
refresh request to get a new access token
using the refresh token.
And then, it'll send a third request, that being to retry
the original request, to the API.
And then if that gets rejected, than it
will send an error.
But like I said, all that happens under the covers.
You don't need to worry about it.
All you need, especially in the case of an MCA, Luke, is
one refresh token, and everything else
just kind of happens.
LUKE: OK.
I didn't know that you had an interfaceless--
I could make like a post with an interfaceless system that
would then respond with the token.
I didn't know that.
DAN HERMES: Yeah, you can do that.
It's server-side OAuth 2.0 is what they call it, and it's a
server-side flow.
It's not quite server-to-server, but you can
do a server-side OAuth 2.0.
And what you'll do there is you'll just get a code back.
So there's a redirect that we offer when you use that
redirect URI, a Google host redirect.
And on that page, they just have a text box with the code
that you need, and that code is what you exchange.
That code only lasts 10 minutes, whereas an access
token lasts an hour.
That code is a very short-lived code that you can
use to exchange for a refresh token and an access token.
But if you just search for server-side OAuth 2.0 flow,
it's in that document that I just posted to the thread.
But if you want to ping the forum if you're having
trouble, I can certainly point you in a
more specific direction.
LUKE: I have a question about--
DAN HERMES: Caroline, does that seem like it's--
sorry, Luke.
Did you have a problem?
LUKE: I just wanted to ask a question
about that last point.
When you bring in these guests, will we be told two
weeks in advance who's going to show up?
DAN HERMES: When I announce the Hangout, I'll announce--
it may not be two weeks in advance, but it'll be 10 days
in advance, 8 days in advance, something like that.
So Caroline, is that sounding more like what you were
looking for?
Or were you really needing this server-to-server flow?
CAROLINE: I think so.
I'm just trying to find where you're looking in the
documentation, because what I had certainly didn't--
the redirect URI was a page where a user would acknowledge
and consent to that.
And we have 200-plus merchants.
To have that kind of set up every time we need to add
somebody to this--
DAN HERMES: So it depends on your setup.
Luke's setup, he's using a multi-client account, and he
creates a sub-account for each of his users.
And then he can just administer those accounts
using his own logged-in credentials, because his MCA
is a parent for all those sub-accounts.
If you have individual accounts for each of your
merchants, one, I would recommend going to an MCA.
But two, you're going to have to get their authentication
somehow to make requests on their behalf.
And asking them for their passwords is not good, right?
So you're right.
CAROLINE: It's less than ideal.
But the way it's been in the past, it's not inconsistent
with what we've had to do in the past, right?
Because this is a relatively new model, too.
So we've been doing this for 10 years with
Froogle and all that.
DAN HERMES: Wow, that's remarkable.
Yes, I don't believe OAuth has been around that long.
CAROLINE: And OAuth 1.0 was--
as my boss said, just use OAuth 1.0, and hack it, and be
done with it.
Because OAuth 1.0 apparently had a number of issues, right?
DAN HERMES: It was just the flow was
a little less intuitive.
There were more parts to it.
And I think one of the big issues with OAuth 1.0 is that
you had infinite life access tokens.
And it's the same thing with client login.
Well, actually, no.
That's not true anymore with client login.
But there's some problems with giving access forever rather
than giving the ability to refresh forever,
and, things like that.
CAROLINE: So the way the documentation is written
certainly suggests we are a server-to-server candidate.
But that said, it does not seem like even in the
libraries that's supported, it's supported too well.
There's a lot of complaints about things not working
appropriately in their respective libraries.
DAN HERMES: That's one of the more exotic flows.
And honestly, I don't think it's that necessary.
I don't know how you're currently authenticating new
users, but it would be as easy as do you want to sign up, and
then it's just one extra page they go through.
CAROLINE: Yeah.
They typically talk to one of our ECI representatives who
walks them through everything.
Because we can have very different people, different
technical backgrounds.
One of my concerns with doing a multi-client account is
we're a software as a service, so we don't have a website.
We don't have a merchant account as a company.
It's all our merchants have merchant's accounts.
So the master one is always the
master and all the children.
And it wasn't clear how to obtain a master account that
wasn't tied to a website that had e-commerce platform.
So we don't want to take one random merchant, make them the
master, and then--
DAN HERMES: No.
It would be your own sub-account.
But the fact that you don't have a website
may be an issue there.
CAROLINE: We have a website, but not an e-commerce website.
DAN HERMES: Right, right, right.
I don't know.
I think with marketplaces, you would need an e-commerce site,
but there are other types of multi-client accounts that
don't necessarily need to be a marketplace.
CAROLINE: So that's one reason that we held back.
The second reason is, obviously, the quota is per
merchant account, and it actually would bite us worse
as a master account than--
we'd more than likely have to get our quotas up, too,
whereas if we just used the separate merchant accounts,
our quotas will be higher, and we shouldn't run
into that as much.
DAN HERMES: In that case, if your quota volume is high, and
you're meeting it, and there are legitimate requests, if
you're not doing something where you're being spammy, or
you're sending more requests than you need to or something
like that, we'll bump your quota.
There are no issues there.
And if there are issues, then we'll help you get your number
of requests down so you're not hitting the quota.
CAROLINE: But using separate accounts, I would unlikely
have to bump it, right?
Well, I mean, it's fine.
It's something we would definitely look at if there's
a way to have a master account that is not attached to an
e-commerce website.
DAN HERMES: I don't know that off the top of my head, but
let me write that down, actually.
LUKE: Well, Caroline, my site isn't an e-commerce website,
and it was approved as an MCA account.
CAROLINE: We tried to get our demo sites approved, and we
just kept getting shot down.
And whoever the nameless, faceless person on the other
side of the drop was was not giving us any help at all.
LUKE: I had the same problem until Sir Danny stepped in.
CAROLINE: So we just went and got our merchant account, and
said, OK, you're going to be the beta merchant.
We'll just start with you.
I mean, we got sort of frustrated.
We tried for probably a month to get something done,
particularly so we could use it as a test platform.
Because we have test e-commerce sites that wouldn't
damage anything as well.
DAN HERMES: So as a test platform, that's actually
against the terms. But what we do with the API
off of the dry run--
CAROLINE: Right, the dry run, which is what
I've been using, yeah.
DAN HERMES: Yep.
But we can certainly, off this Hangout-- you and I,
Caroline-- link up about doing an MCA if you're interested.
And I can certainly help with those channels that you said
weren't that helpful, because I agree.
There are times where the sign-up flow and things like
that are not as intuitive or human interactive as--
CAROLINE: You'll probably get a kick out
of the email, Danny.
I'll send it to you.
It was pretty entertaining, actually.
LUKE: It was a two-step process for us.
I mean, not only did they decline when we first tried.
They also turned off our appy access.
So I had to go back to Danny twice and get it finally done.
DAN HERMES: So with that said, to conclude that whole arc, I
think OAuth 2.0 server-side is a pretty viable flow.
But again, you're going to have to make that decision.
The docs are a little hard to digest, but I think after you
implement it, the docs are a lot easier to digest after you
try it out a few times.
CAROLINE: I think you're just looking at a different doc
than I am, because there's certainly none that suggests
that there's a generic redirect URI you can use, so I
just didn't find the right document.
DAN HERMES: Yeah, so maybe I'll reread that and find out
if it's in there.
When you actually go into the Google API's console to
actually get your client ID and your client secret to do
OAuth 2.0, by default it's server-side OAuth 2.0.
And you have to actually change the setting to set your
own redirect URI.
By default, it's actually set to be--
CAROLINE: Oh.
See, I didn't even do that.
I just did the server-to-server, because that
seemed like the appropriate one from the document.
DAN HERMES: So the server-side OAuth actually, either using
local host, which you need to do--
your library needs to support that.
So local host isn't really the one you want to use, but it's
something like EEB colon-- you know what?
Let me mute myself and type that in.
Not that it matters that much.
But I'll be right back.
CAROLINE: Yeah, it doesn't matter.
You can just post it later, too.
It's not that critical.
It does make me question why we have a server-to-server
option when it doesn't appear to be supported or encouraged.
It's like, why is that there?
ANDREW: Have any of you guys read the OAuth 2.0 spec to see
if message signing is still part of the--
I haven't done OAuth 2.0.
I've only done OAuth 1.0.
No?
CAROLINE: The service accounts, that last piece I'm
talking about, definitely
includes an RSA hash signature.
ANDREW: For the header or for the whole message?
CAROLINE: Just the payload.
The header's encoded, 64 encoded, and then
the payload is signed.
Actually, no.
The header and the payload are signed.
So you send the header, the payload, and then the signed
header and payload all as one parameter.
DAN HERMES: That's the point of the RSA, is that you can
encode the payload.
ANDREW: They could just use the transport
layer security there.
DAN HERMES: Right.
ANDREW: But I guess they decided to go the more
complicated for me way.
CAROLINE: But using that first method that Danny talked
about, it's almost seamless.
There's really no encryption.
I mean, that's all handled in the library.
ANDREW: I'll have to look and see if there's a good library
that I can use.
Because I'm sure that the Google Client Library for this
uses it, but we did some custom code.
DAN HERMES: All the source is open source.
So you if you need to pull parts into your own custom
stuff, the source is still out in the wild.
It's not just a bunch of executables floating around,
or binaries.
So I did find that string.
It's urn:ietf:wg:oauth:2.0:oob.
Not that anyone should remember that, but that's
approximately what it looks like.
And before we get to our next question, I just want to say I
see we have two viewers outside the Hangout.
We have, let's see-- one, two, three, four, five.
There's only six of us right now, so we have four open
spots if you want to actually join the Hangout and not just
watch from afar, and hang out on air.
If you prefer to watch than hang out on air,
that's fine as well.
Anyhow, on to our next question.
Yule or anyone?
Anyone?
LUKE: I have my usual question or two.
I did get an exception for items that include group item
ID must not have multiple values.
And this was because a merchant was trying to submit
two colors.
And the way I take them is I take them as a comma separated
list, and then I just parse them out of the comma
separated list and list them separately.
So how do you want that submitted if it's like blue,
white, blue, red.
Do you want blue comma white, or slashes, or--
DAN HERMES: Well, so if it's like they have four of the
same shirt that are all in four different
colors, that's one case.
Or if they have a shirt that has four different colors,
that's another case.
So which one do you mean?
LUKE: Well, let's just a take an example of two.
You have two shirts, and they're each multi-colored,
but there are two colors.
Like it's a blue and white shirt, and a
blue and red shirt.
And you can only submit the attribute for
the color one time.
So do you want blue comma white, blue comma red, or blue
space white, blue space red?
DAN HERMES: This is the sort of an amalgam
of everything, right?
So if you just had a shirt that was both blue and white,
a multi-colored shirt, and you would submit blue
slash white, right?
Now, for this particular product, you have a shirt that
sells blue-white and a shirt that sells red-white.
So you could submit two different products with the
exact same data, one blue-white, one red-white.
And we actually have support for this through variant IDs,
and that's actually--
LUKE: But not like that, though.
I mean, the shirt itself has two different colors in it.
So you're submitting one color attribute for one product, but
you want to put two colors in the attribute.
DAN HERMES: Right.
So what the docs say, whether you're using the API or
whether you're using data feeds, you need to pick a
dominant color, and then from there, list the rest after it.
But the example we have in our example XML in our docs says,
I think, red slash blue.
But in the single attribute, you would do blue slash white.
So scp colon color red slash white, blue slash white.
So color, actually, before we made the big switch to all the
variant IDs, you used to be able to send
more than one color.
But now you can only send one color.
But read up on variant IDs.
We can discuss it a little more if you
have specific questions.
LUKE: Yeah, I'm already using variant IDs.
DAN HERMES: Oh, OK.
Perfect.
LUKE: I'm doing all that.
Just I've gotten this weird error about how you can't
submit them as separate color values.
DAN HERMES: Yep.
You need to submit one color, and then, like I said, if
there are two multicolored versions of the same shirt,
then you would need to submit them as separate variants
under the same variant ID.
LUKE: And I have a stupid question.
Are digital downloads considered hard product that
we can list?
See what I mean?
Because it's like, let's say you have a report.
It's a bound report, right?
That's something you ship.
That's a hard product.
But what if you want to offer a digital download version.
Could that also be listed with the appy?
Because it's a digital product.
DAN HERMES: I don't know why not.
I don't know the specifics of it.
Let me write that down.
As far as I know, if it's a product, it's a product.
But I don't know 100%, so we'll leave it at that.
And I'll write this down.
I'm going to mute myself so you can't hear me typing.
LUKE: I think it's a stupid question just because I feel
like I'm too lazy for not digging.
I'm sure it's in there somewhere.
It's in the doc somewhere.
DAN HERMES: Sure.
Do we have any questions from our newcomer, Hope?
No?
Are you finding this helpful?
That's good, that's good.
HOPE: Yes, thanks.
MALE SPEAKER: I've got a question to ask about
documentation.
DAN HERMES: OK.
What's up?
MALE SPEAKER: You sent out a link on the forum this week
that the documentation's being changed or updated?
It's also labeled "sample documentation."
DAN HERMES: What's that?
MALE SPEAKER: It was labeled "sample documentation?"
DAN HERMES: Yeah.
So, it's not that something was being changed.
It's that I added an end-to-end PHP sample that
showed you how to insert products in batch or
individually, how to update, like, pretty much every action
you would want to do on your items using PHP.
And I have one in Python that I published three weeks ago,
and hopefully, the DotNet will be published this week.
I don't know if people saw all the commits made to the DotNet
library, but it's just a new guide.
It's just augmentation rather than changes.
MALE SPEAKER: Excellent.
Thanks for clarifying that.
DAN HERMES: You're a Java guy, though, right?
MALE SPEAKER: I am Java, that's right.
DAN HERMES: So you don't care about the PHP.
MALE SPEAKER: I had a quick glance at the PHP.
It looked good, it looked good.
DAN HERMES: Sure.
OK.
So do we have any other questions or concerns?
CAROLINE: Hey, Danny?
I do have a question.
I know you kind of pushed me to go down the web server
application route.
It's still an additional step.
I mean, you have to have them set up a merchant service
account to get either the client secret and client ID or
to get the private key.
DAN HERMES: No.
I wasn't advocating you do that.
Your application has a client ID and a client secret.
And then your application performs OAuth 2.0 as--
CAROLINE: Got you.
But then again, we would still need to have a master service
account, right, to do that?
Or no?
DAN HERMES: No.
CAROLINE: Doesn't that account have to be
attached to a merchant?
DAN HERMES: That doesn't have to be tied to
your account at all.
CAROLINE: OK.
That I was unfamiliar with.
Now I got it.
DAN HERMES: So what happens is, you need to sign the
request on behalf of someone, right?
So OAuth 2.0 is a way to get a token for doing the signing.
So if you get a token on behalf of your users, it
doesn't matter what account retrieved that token, right?
It's a token for the user's account.
And when you sign the request on behalf of your users,
that's what that is.
So you could use a Google account completely independent
from the accounts you're using to manage everything else.
But you could use that account for OAuth when you go through
and set it up, and you'd be fine.
So you need one client ID and one client
secret for just you.
And then from there, you'd use that client ID and that client
secret to actually construct the token--
CAROLINE: The OAuth request, yep.
DAN HERMES: Right.
And then from there--
there may even be a video online.
I might try to track that down.
But from there, your user is presented with one page, two
pages if they're not signed in.
CAROLINE: Yeah, I think it's seeing the page where they
agree to it and all that.
DAN HERMES: And it even says--
because you specify the scope in the request, so it'll even
say, they're only wanting to access your Content API for
Shopping data.
So all our tokens are scoped tokens.
So if you've got an OAuth token, and then you try to
access, let's say, their calendar
data, that would fail.
CAROLINE: Right, right.
Yeah, that's pretty clear from the documentation.
So then with that question in mind, say I am using whatever
generic Gmail account that I have, and I do the
server-to-server.
How am I able to access their accounts, the
very last one that--
DAN HERMES: I'm not familiar enough with server-to-server
to tell you.
CAROLINE: Because maybe there's enough trust in that
original account?
I don't know.
Again, it seems ideal to not have to have their
interaction, but it's just unclear from the documentation
what that last one is.
DAN HERMES: I don't understand how you're going to get their
authorization without some interaction.
CAROLINE: Well, that's what I'm asking you.
The service-to-service account, if the private key
generated is not associated with their account, then how
is that an authorization?
Because my understanding was they
created the project account.
They generate a private key that is for their merchant
account, and then everything signed with their
private key is golden.
DAN HERMES: I see.
OK.
Yeah.
CAROLINE: Maybe if we had a better understanding of how
that works.
DAN HERMES: Like I said, I'm not familiar
enough with that flow.
It is one of the more exotic ones out there
for the utmost security.
Yeah, I mean, like Andrew said,
usually TLS is good enough.
But that goes above and beyond.
But I can look into it more for our next
Hangout, if you like.
CAROLINE: Yeah, or even just post on the forum sort of how
that queue thinks, as well as if we go that direction, their
response error is, on purpose, useless.
It's just that didn't work.
And I think that's so that you don't try to hack it and keep
trying to get the right answer, right?
I think it's by design that it's a obtuse error message,
but having maybe more information as
to why that's happening.
I mean, it does appear to be used.
There's enough people on forums talking about it.
Maybe it's only used for--
DAN HERMES: Individual accounts?
CAROLINE: Or individual APIs that really don't contain any
kind of sensitive data, and that's the whole point, too.
I don't know.
It's just not clear.
DAN HERMES: Yeah, I mean, especially with this API, all
the data is intended to be user-facing.
So we don't really care about encrypting it that much.
User-facing via either commerce search, or product
search, or product ad, some other destination.
CAROLINE: And the worst thing somebody could do is if they
got your account is to get it shut off.
I mean, that's not good, but it's the worst they
could really do.
DAN HERMES: Sure, sure.
CAROLINE: Sorry.
I'm done beating that particular dead horse.
DAN HERMES: No, no, it's fine.
It's very important.
I think especially with client login going away, it's
important to understand how all these flows work.
But also that's sort of the new way authentication happens
on the web with OpenID and OAuth.
It's not just Google.
It's everybody.
And with a lot of these libraries, client login was
super-duper easy.
You just put in the account ID and the password,
and you just go.
Or that is, the email, not the--
merchant center account ID.
But I think that stuff's pretty dangerous.
There was a talk last year at Google I/O, called Client
Login Fail, going over all the ways where
bad things can happen.
It is kind of scary having to send passwords around.
That's why we rely on these millennial flows rather than
the old school.
LUKE: Danny, I wanted to ask if anybody had seen this
happen, and maybe I just need to double check.
But it looks like when a product is posted, the
Merchant Center Console shows a created date-time and an
updated date-time.
And at some point thereafter, it switches over and says
posted, right?
And it doesn't say created or updated.
It just changes the display?
DAN HERMES: I'm not familiar with the
posted attribute, but--
LUKE: It might even be after the product
is approved or something.
But anyway, the post seems to change, and it says posted.
And then, what I think I noticed, and I've got to
double check this, is that when it switches over to
posted, the appy starts returning an updated
date-time, but it doesn't tell you when
the product was updated.
The updated date-time comes back as the current date-time
of the request. Maybe I'm wrong about that.
I don't know if anybody else noticed or not.
DAN HERMES: Huh.
So I did ask about that before you were asking about updated
and published signatures changing.
The team says either that's a bug on our part or you're
making some sort of changes before doing that that you're
not registering or realizing.
LUKE: I need to double check.
Let me check my stuff and make sure I'm right.
DAN HERMES: Yeah.
I don't know the behavior of all this.
Nobody's really noticed it.
I'm not sure.
But unless it's critical to your application, I'm not too
worried about what the values are or not.
I don't know.
If it is critical, you want to know when it ends up on
product search or something like that.
LUKE: I think originally what I was doing was I was
comparing your date to when it was updated to my system's
date that was in the process of updating and that was
determining whether I should fire an update.
I do it internally now, so I can keep track of when it was
last modified, and I compare it to the current time that
I'm running to determine whether or
not I should update.
DAN HERMES: I would recommend doing that, and possibly even
maybe Andrew can talk about scalability a little bit.
But possibly even saving responses for some
predetermined amount of time so you can go back through and
get stuff out that you wanted.
But for somebody like you where you have an interaction
with the user, and the user is actually changing something in
the database, it's not too difficult to have a database
hook where you either add something to a queue or you
immediately fire off a request.
LUKE: Right.
You're right.
DAN HERMES: I don't know if you wanted to make a comment,
Andrew, about what you guys do or what you think a best
practice is, for how long you should save responses or how
often you should save responses,
or things like that.
ANDREW: For us, it's a little easier because we have so many
different things that consume this product data that we
actually already have a system where every change has a time
stamp, and you can compare the last time stamp that you sent
to the time stamp of when the change happened.
But I keep separately a record of the last successful send.
I don't query the data back from Google.
I just assume if I got back a "2 something something"
request or response, like a 200 or 205, then the change
committed to Google, and I don't have to tell them about
it again for another month or until another change happens.
LUKE: Did you notice, Andrew, if the updated date-time
reflected the current time?
Or have you just never looked at that?
ANDREW: I haven't used the DotNet framework for that, and
I haven't looked at the responses.
I don't plan on using that.
DAN HERMES: I mean, he's just referring to--
they're in the Adam Namespace--
published, updated.
I think he's saying posted also.
They're all in the Adam Namespace, and they come back
in the responses.
ANDREW: And I actually thought that was supposed to indicate
how fresh the data was.
not when the data was changed in Google's database.
It was a long time ago that I looked at that particular
thing, but I thought that was to indicate for like if you
had a client that was getting multiple pieces of data or
interacting in some way.
So the current date-time might actually be right in that
case, or at least at the date-time of the request
DAN HERMES: Like some crawl to a product page, you mean?
ANDREW: No.
I was thinking like if you do an API request and it comes
back with a time stamp on the response, I thought that was a
time stamp for how fresh the data in the response was, not
when the data changed in Google's database.
LUKE: I guess it doesn't matter that much.
I probably should let you know, Danny, if that's the
case, that it is giving you the current date-time in case
your engineers had really meant that field to mean the
last time it was updated in your system just in case it
comes up in the future.
DAN HERMES: Let me experiment here.
I'm going to use our demo, and actually just make a request
and find out what happens.
I will share the screen in a second.
Actually, no I won't.
I don't want to reveal my account ID, unfortunately.
Sorry.
CAROLINE: I had a pen all ready, too.
DAN HERMES: Actually, it goes on YouTube,
so it's never gone.
ANDREW: I think it might be relevant to mention that the
account IDs, I know everybody in the forum spends a lot of
time trying to hide them.
They're actually not very secret.
You could get them off of the Google merchant--
you can get them off of the shopping search.
And actually, they're also somewhat sequential.
So you can kind of guess, like the last number has some
repetition in it, but the rest of them are pretty sequential.
But yeah, I know there's people who are like, I don't
wanna know--
I don't want people who know what I've been posting.
DAN HERMES: Yeah, so I am noticing that the updated time
stamp reflects the current time, and the published time
stamp did not change.
But I don't know what the implications of that are.
And I don't see a posted time stamp, but this account
doesn't really have anything posted, so suspicion confirmed
to a degree.
So, do we have any other questions, or are we
going to wrap up?
MALE SPEAKER: Danny, just a quick one about OAuth.
ANDREW: Thanks.
MALE SPEAKER: Sorry, Daniel, sorry.
Just a quick question about the OAuth.
I've had a quick look at the documentation.
It's great you've got it in the PHP, OAuth 2.0.
I just had a glance at the Java, and it says coming soon.
DAN HERMES: Yes.
So, I didn't write the Java one.
And that was actually in reference to
OAuth 1.0, I assume.
It's on my list of things to do.
I just finished the other three guides, because they
didn't exist. The Java one has existed for months.
MALE SPEAKER: It's OK.
It was just a comment, really.
I wasn't chasing you or anything.
DAN HERMES: I don't know if you're using the client
library or which client library you're using, but they
have instructions within the source.
So if you're using the Google API Java client or whatever.
I can't remember the name 100% off the top of my head, but if
you're using that one and you go to the wiki, there's a long
OAuth to wiki explaining exactly what you want to do.
MALE SPEAKER: Thanks.
DAN HERMES: Sure.
All righty.
Well, I'll see you guys again in two weeks.
I will make an announcement relatively soon whether or not
I'll be having somebody as a guest star.
And I will post some of these questions that we had, like
this published or not question and what the relevance of the
keys are in server-to-server things, and then also about
getting an approval for an MCA without an e-commerce site.
CAROLINE: Yeah, I'll send you the email I have just so you
have whatever you're looking for.
DAN HERMES: All righty.
CAROLINE: Thanks, Danny.
DAN HERMES: Have a nice day, everybody.
See you.