0

Say I have a variable URL = 'http://200.0.0.0:10' and I use this in all of my calls like this (URL + '/logon') as my path. If you go into Google's dev tools you can find my address and port (the URL variable).

How can I hide my URL variables (address & port) in Angular?

ANY suggestions are welcome, I just don't want the front end to be able to know what my address & port is (or any other important variables I would like to hide).

I have tried:

  • Putting the URL variable in a shared.service.ts and then creating the url like this (this.sharedservice.URL + '/logon'). This doesn't work because you can still see the sharedservice.URL variable from the front end.
  • Putting the URL variable in the environment.ts and then creating the url like this (environment.URL + '/logon'). This doesn't work because ng build compiles the url path into this: ('http://200.0.0.0:10' + '/logon')
Improve this question
5
  • So you are talking about cosmetic issue here, or you want to hide connection details from end user? Letter is not possible ;P Commented Oct 22, 2018 at 8:35
  • Write your own browser and force user to use it ;) Commented Oct 22, 2018 at 8:36
  • Instead of hiding some data from url. You can just use this way. Redirect user to dashboard whenever they try to edit the URL so that even if they know some id they can't do anything Commented Oct 22, 2018 at 8:36
  • @GvsAkhil — That would depend on being able to detect the difference between a URL generated by the user and a URL generated by the app, which isn't possible. Commented Oct 22, 2018 at 8:43
  • No @Quentin we use that method in asp.net. When user tries to edit URL he gets logged out Commented Oct 22, 2018 at 8:50

2 Answers 2

Reset to default
2

You can't.

You need the browser to make requests to the web service.

Therefore the browser has to know where the web service is.

The browser belongs to the user.

Anything you tell the browser, you also tell the user.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Don't you agree that front end applications are bad then? Because they are easily hackable?
@FreddyBonda — No. If people can do bad stuff with your API then that's the fault your API design, not the frontend.
Aaaah ok. Do you have any links on good API design for security? At the moment we have a jwt token that is passed by the cookies. The logged in User also has this token assigned to their profile in the db. If the two match, then you can use the API. Else you can't. If the user logs out then the token is removed from the profile in the db. Is that enough?
-1

Build standalone application insteed of web based one, if you want to have that much of freedom - but still, I will be able to know where outgoing comms are going .

Improve this answer

3 Comments

Don't you agree that front end applications are bad then? Because they are easily hackable?
It is a disadvantage that those are exposed, but are they "hackable" ? Well you dont wan't to make frontend secure, but backend services. After all, I don't need your application to hit your api just like app would.
Ah ok. So the same idea @Quentin, "If people can do bad stuff with your API then that's the fault your API design, not the frontend"

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.