Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMP Access expression grammar #1633

Closed
carlosabalde opened this issue Jan 28, 2016 · 7 comments
Closed

AMP Access expression grammar #1633

carlosabalde opened this issue Jan 28, 2016 · 7 comments

Comments

@carlosabalde
Copy link

I would like to clarify a couple of simple questions about the AMP Access expression grammar:

  • Are dots, dashes and/or underscores allowed in the names of properties returned by the AMP Access authorization endpoint? The expression grammar is slightly ambiguous about this.
  • Are string comparisons allowed in AMP Access expressions?
@carlosabalde carlosabalde changed the title AMP Access authorization response AMP Access expression grammar Jan 28, 2016
@dvoytenko
Copy link
Contributor

@carlosabalde a more complete grammar is here: https://github.com/ampproject/amphtml/blob/master/extensions/amp-access/0.1/access-expr-impl.jison

Are dots, dashes and/or underscores allowed in the names of properties returned by the AMP Access authorization endpoint?

No, dots, dashes or underscores allowed. Underscores is rather unfortunate and I will fix it asap. But I think dots and dashes will not be allowed.

@dvoytenko
Copy link
Contributor

@carlosabalde

Are string comparisons allowed in AMP Access expressions?

Yes.

field = 'abc'
field != 'abc'

@dvoytenko
Copy link
Contributor

I updated the grammar. Names now allow underscore.

@jugglingcats
Copy link

Is there a reason nested objects are not allowed, eg.

field: { prop1:'value' }

Sometimes an access decision can contain quite complex information needed to message the user, and flattening this into name value pairs is restrictive.

@dvoytenko
Copy link
Contributor

No strong reason, no. Mostly it's meant to insist on simpler structures given that the authorization response is free-form and designed specifically for the needs of access. And we'd definitely like to limit the depth, e.g. to only the depth of 1 (object.field). Do you see it really needed? Could you share an example or two?

@jugglingcats
Copy link

Thanks for reply. A metering response might look like this:

{
  "action": "login",
  "exceededMeter": {
   "period": "WEEKLY",
   "max": "10"
  },
  "authenticatedMeter" {
   "period": "WEEKLY",
   "max": "20"
  }
}

In some cases complex messaging would be left to the login page, but you can imagine using amp-mustache directly to render a message like:

You have exceeded your meter count of 10 articles per week.
But you can get up to 20 articles per week by registering.
Register or sign in now to read this article!

Obviously the data can be flattened but this is not very scalable.

@dvoytenko
Copy link
Contributor

Sounds good. I moved the request to #1919

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants