#Angular is not saving cookies to the storage
230 messages ยท Page 1 of 1 (latest)
The post method looks like this: ```ts
@Injectable({ providedIn: 'root' })
export class ApiService {
constructor(
private http: HttpClient,
@Inject(API_URL) private api_url: string
) {}
post<T, D>(url: string, data?: D): Observable<T> {
return this.http.post<T>(${this.api_url}${url}, JSON.stringify(data), { headers: this.headers });
}
get headers(): HttpHeaders {
const headersConfig = {
'Content-Type': 'application/json',
Accept: 'application/json',
};
return new HttpHeaders(headersConfig);
}
}
What's the url for the backend?
That looks like the angular url
Ah backend is 7175
So yeah cookies are set for that tho, not 4200
Are the cookies sent across correct? That's all that matters.
You probably need withCredentials tho
withCredentials might be the problem indeed
Still not working
This is the configuration on the backend
Damn, my browser blocks them
This is the default Chrome settings, this means my auth is useless
Third-party cookies get blocked
Okay I must switch to Auth0
We also use third party cookies
And based on what we discussed, the setup would be the same
Ensure api and app share the same domain, cookies are no longer third party then
That's all why we don't do cookies by default in SPAs
Its the best, but not always easy or even possible depending on your setup
Is it still considered a good practice to enable third party in the browser during development? Outside development, the app and backend would need to be deployed under the same domain
I mean, having the same domain should not introduce complications. If it is possible to set up the same domain on 2 different cloud instances (never done that) then I do not see any problem
There's usually a CDN/gateway in front of them, otherwise you'll end up with different IPs
But you could do api.mydomain.com vs mydomain.com
(don't remember if it'd be considered third party)
Then it is a win win
Would I encounter the same problem if I managed login on the backend with Auth0 instead of the Universal Login?
๐
Yeah
Your API and FE still need to be on the same domain
Every cookie that isnt on the same domain causes the same issue
You can avoid it by not using cookies.
Which has its own set of consequences.
Which, again, is why our SPA SDKs do not use cookies.
But still cookies is superior, as long as they are HTTP ONLY
I think it can be a challenge tho for local development.
(But I assumed you had already figured that out as it sounded like u had the HTTP ONLY cookie setup working with your own implementation)
For development it works if I allow thrid party cookies, now I receive them
Yeah
Thats true.
But is that a stting u can configure per domain?
Or is it for the entire browser ?
(I have never looked at the settings ๐ )
It can be set per domain
Great!
yes, but for now I could not add the localhost:port, did not work
Looks like api.x.tld and x.tld works though, with cookies
that is perfect
If you use something like cloudfront you can easily do * going to your frontend and /api going to your backend too
(cloudfront, nginx, cloudflare, etc)
for now don't deploy it, but do implementations to be easily configurable. For example, factory methods construct the right instances based on the current environment.
Hm not sure what you mean, all this is fairly external to the app
Or you mean you have a configurable API endpoint base URL?
Because that essentially boils down to having a string or Observable<string> (or URL)
(please don't use Angular environments ๐ฅฒ)
Did I get it right? If they run on the same domain then the sameSite should be strict?
same-site means the base domain is the same, so www.x.tld to api.x.tld would work too
perfect
Isn't it a thing to use environment on the frontend? I don't know, for some configurations?
(it's a bit more complex than that because there's some kind of list of what counts as a tld and it's not just actual tlds, iirc stuff like github.io counts as a "tld" too but still)
Does having to rebuild an app because a URL change sound like a good practice? ๐
Environments can have their use but it's more a build configuration than a deployment environment, sadly the naming made it.. drift
Luckily for you, Auth and Environments are my two things I hate when people do it wrong, here u go: https://dev.to/thisdotmedia/runtime-environment-configuration-with-angular-4f5j
I believe u should use runtime configuration and not compile time configuration
Well, at least they didnt support .env files, like we have with react and vue.
Which is ... probably worse.
(and dont get me wrong, I like react. But the introduction of .ENV files is just confusing for people that arent aware there is no concept of environment variables in the browser)
It sure is
It's also why new devs take the first day trying to get environment variables working ๐
(first day for the good ones)
๐
Sorry this always opens a pandora's box
๐
The holy conf crusade
For now I only have env configuration on the backend which happens on build. Now that the Cookie differs based on the environment I am wondering if I should do it like this:
But I think I should not
this does not happen on build time, rather when creating new instances
env config doesnt happen on build in the backend tho, if u mean appsettings etc
ah
thats what you said
I should read everything
lol
This is how I did with token settings. In prod the secret would normally be stored securely in a vault and would be accessible upon request. So that would require a different implementation to set the fields
Is this good or can be done better?
Iirc that can be done better
I mean, u can auto-map config sections to classes
and no need to manually map them
Let me try and find that
builder.Services.Configure<DevAccessTokenSettings>(
builder.Configuration.GetSection("JwtSettings"));
Next, whenever u need it u can just inject it
private readonly DevAccessTokenSettings _options;
public SomeClass(IOptions<DevAccessTokenSettings> options)
{
_options = options.Value;
}
Yes, and what happens when the environment is not development? The values would not come from a file
๐
You are solving problems that do not exist.
Learn how to use the Configuration API to configure AppSettings in an ASP.NET Core app.
If u have a FOO thing in your appsetting
AND you define a FOO thing in your environment variable
on the server
the env variable wins.
and the appsetting is ignored.
Thats why u use the concept of "Configuration"
U dont just read from the appsettings file
u read from the .NET configuration system
which has different sources it reads from
What is FOO?
Learn how to use the Configuration API to configure AppSettings in an ASP.NET Core app.
FOO is a random string
So u have JwtSettings:AccessToken:Issuer, right?
"AccessToken": {
"Issuer": "https://localhost:7151",
"Audience": "https://localhost:7151",
"SecretKey": "secret",
"ExpirationInMinutes": 15,
"ClockSkewInSeconds": 5
},
If u read the link I shared, what u want is to define an environment variable on the production server like this: JwtSettings__AccessToken__Issuer and its value will override the one in appsettings.
I understand, evrything will be loaded from appsettings
Thats not true. Well, it does read from appsettings, but not solely
Configuration reads from all of that
appsettings is just the first layer.
If u define ANYTHING with the SAME NAME in any of those other laters, it overrides it.
So what u want to do is just use this:
builder.Services.Configure<JwtSettings>(
builder.Configuration.GetSection("JwtSettings"));
then, by default everything uses appsettings.json. Now lets say you want to use a different Audience on your deployed version, then you just define an environment variable on that server: JwtSettings__AccessToken__Audience and set it to something else.
Oh so probably there is an option before build to get the Secret key from the Vault that overrides the default one. Or simply inserts if if it was not specified
Will use this, thanks
Its explained in the link I shared: https://learn.microsoft.com/en-us/aspnet/core/security/key-vault-configuration?view=aspnetcore-7.0
But the summary is
U do this in program.cs
builder.Configuration.AddAzureKeyVault(
new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"),
new DefaultAzureCredential());
and it auto connets things for u. All u then need to do is ensure things use the correct name.
Did not check the 2nd link, sorry
(I mean, cponnecting AzureKeyVault is a bit more complicated, but in essence that is how u connect it to the Configuration)
You should not worry about environents, but just straight up read from the Configuration.
I have deployed tons of .NET API's like that to numberous of environents
(e.g. I have worked in horror set ups were we had: DEV, TEST, QA, PREPROD, PROD and DEMO environments)
And I was able to use different configs for all of those without needed what u tried.
Impressive, I just went Java style here :c
The configuration in aspnetcore is cool
Spring Boot has pretty much the same feature though ๐
Doesnt matter
All good
Just sharing so u know it exists
there is too much out there to know it all
I would need the DevAccessTokenSettings in the AddJwtBearer
I do not think it is possible to do that
I think there are solutions for that
but might be a bit awkward yeah
But you are reinventing the wheel here
See: Simplified configuration for the JwtBearer middleware
with .NET7, JwtBearer can auto-map to appsettings.
// appsettings.json
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.AspNetCore": "Warning"
}
},
"Authentication": {
"Schemes": {
"Bearer": {
"Authority": "https://{DOMAIN}",
"ValidAudiences": [ "{AUDIENCE}" ],
"ValidIssuer": "{DOMAIN}"
}
}
}
}
If u use that structure
(its auth0 blog psot but unrelated to auth0 specifically in this case)
Thank you.
I am using .NET 7, but since I am using cookies now, there is no Bearer
๐ right
Wait what ?
Your own snippet literally says AddJwtBearer
Sorry, I am struggling with a configuration. Did not change the JwtBearer yet
It has null value
Isn't this code snippet correct?
Can u shw appsettings
"EmailEncryption": {
"Key": "test_key",
"InitializationVector": "test_vector"
},
And the class: ```ts
public class DevEmailEncryptionSettings
{
public string EncryptionKey;
public string InitializationVector;
}
well I see a problem
Also want to get rid of all the Dev prefixes, but thats unrelated
One variable name is not the same
Yeah the name needs to match
yes, once it works
๐
no
So whats bnot working? Whatsnull?
private readonly DevEmailEncryptionSettings _emailEncryptionSettings;
public EmailEncryptionHelper(IOptions<DevEmailEncryptionSettings> emailEncryptionSettings)
{
_emailEncryptionSettings = emailEncryptionSettings.Value;
}
IOption cannot be instantiated, I did not register it with AddSingleton or AddScoped
Does it help if u make it a property instead of a field? ๐ค
Yeah you should make it properties.
(explained in the link I shared ๐ )
That should not be needed.
Need to search it up, idk about that concept
๐ works like a charm
I think since .NET 7 there is a warning when a string property is not initialized
Should any of these suggestion be used to suppress the warnings?
public String Test { get; set; } = String.Empty
Wow, only 3 files remained from 9, clean
๐
UX question: Having a confirm password input field limits the chances of a user making a typo in his password. The downside is that he needs to type more. What are your thoughts on this?
My opinion?
A password should not be something u type.
So a confirm field should be useless
Sure if u use ILoveBrocolli and u mistype, your problem
It should be Ahfi&โฌ++uek__ to begin with
(which i do not even want to type twice, why ask me to paste it twice)
I have that
The form has better eyes than yours
How do I know if a service should be registered with AddScoped or AddSingleton? When a service is used in a Controller is it right away AddScoped?
Always AddScoped, unless u know u need singleton
Which u generally dont need.
Understood, thanks
Do u know the difference ?