you could name your paths in an unintuitive fashion manually, and then do some kind of reversible transform to represent resource ids (e.g., represent resource ids as a long base64 bitstring, say like how mongo does UUIDs) which you convert into requests for real ids on an http interceptor (your code issues GET /potatoes/1934kfikwe048wq and the interceptor changes it to GET /potatoes/23
Still- the better thing to do is just make sure the backend code issues 401 (not logged in yet) and 403 (logged in, but you can't see this) and 404 (not my bag, man) errors and have your front-end deal with that. Your users will *want* to make URL changes sometimes. Like when I know in google groups how to go from one group to another without clicking links, but just by changing the URL in the current address. This is a feature, not a bug. e On Thu Nov 27 2014 at 8:16:35 AM Dan Rybij <[email protected]> wrote: > I get it, and I know that protecting data on the back end is required - > and I will be doing that in addition to front-end protection. I just have > to think of a repeatable way, so I'm not constantly writing protection code. > > But is it possible to use decorators to obfuscate the path and query > string? > > -- > You received this message because you are subscribed to the Google Groups > "AngularJS" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/angular. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
