Altinn
all refs to altinn3.no changed to go to altinn3.localho.st
Description
As with using altinn.local.cloud on the app-frontend-react project we need to make it simpler to do run studio locally as well.
Therefore this pull-request will try remove the need of editing the hostfile, and update the Altinn Studio url from altinn3.no to altinn3.localho.st. The url is subject to change, but can be simply done by doing a search/replace on that exact string.
Verification
- [ ] Your code builds clean without any errors or warnings
- [ ] Manual testing done (required)
- [ ] Relevant automated test added (if you find this hard, leave it and we'll help out)
- [ ] All tests run green
Documentation
- [x] The documentation is updated in the readme.md files by removing the altinn3.no mentions.
There might be issues with cookies when different apps run on the same domain, and changing domain is somewhat disruptive. Otherwise I think any time is a good day to get rid of hosts file edits.
There might be issues with cookies when different apps run on the same domain, and changing domain is somewhat disruptive. Otherwise I think any time is a good day to get rid of hosts file edits.
Hmm, so a different domain is required then?
I don't know if a different domain is required (obviously things can be made to work on the same domain). It's just my answer for potential issues that might surface when merging this.
I kind of like the idea of using different domains, as that makes it pretty easy to merge the nginx loadbalancer for studio and apps, so that you only need a single one. That will reduce the cognitive load when switching between studo and apps, as you don't need to ensure the correct loadbalancer is running.
@altinnadmin can we get another sub-domain like (local)studio.altinn.cloud to point to 127.0.0.1 or maybe make it possible to point any *.local.atinn.cloud to 127.0.0.1 in the future?
Who is owning localho.st? Seems to have been used since 2000. Can we assume it will always work?
@ivarne I changed the PR, so it is pointing to altinn3.localho.st for now... I think it is at least a step in the right direction to get rid of the hosts-file edit step. @nkylstad @mijohansen @TomasEng WDYT?
Kudos, SonarCloud Quality Gate passed! 
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
70.0% Coverage
0.0% Duplication
![sonarqubecloud[bot] avatar](https://avatars.githubusercontent.com/in/12526?v=4 "Published by a pub.dev verified publisher"){kind=small}
Who is owning localho.st? Seems to have been used since 2000. Can we assume it will always work?
Good point, but I think that we should just change this for now (local-dev) and then do a search-replace when someone comes up with a better option. I've asked @altinnadmin if another dns can be made for studio, but he has not yet answered. Maybe this is causing some of the tests to fail? The benefit of using something else than local.altinn.cloud now is that a search replace will be easier by setting the dns to something else for now.
SonarCloud Quality Gate failed. 
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
0.0% Coverage
0.0% Duplication
@mjulstein
I guess we should not point our devs to a domain we don't control. Seems risky, an unneccesary attack vector.
The obvious and "correct" solution is to use local.altinn.studio which allready points to 127.0.0.1.
Only challenge there is that altinn.studio is setting strict-transport-security: max-age=31536000; includeSubDomains HTTP header, forcing all altinn.studio subdomains to use HTTPS.
@altinnadmin I don't see that as a major issue in terms of https. Actually once we have that up and running we won't have to deal with switching between all the time.
Many third party tools are also limited to only using https, so if changing to https is the issue here I don't see why we shouldn't
@ivarne also has a point, registering altinn3.no would be a pretty fast and simple fix to this.
On the other hand, we could also make it so that we only set the url once in one location (environment variable?) and can then allow the local developer of studio choose for themselves where they do development. I also do not see the issue of changing the local dev url to something we don't control, as we can just set up a test to ping altinn3.localho.st once in a while and if the ip changes from 127.0.0.1 to something else, we can change to a different provider.
Also is there a reason why we don't just use localhost or 127.0.0.1 other than aesthetics for altinn-studio development?
This is solely for local development and will reduce the overhead of getting started for new devs. I don't really think there is an actual issue with caching etc as this is just a way to avoid the need to edit your local hosts file. We would most likely turn off cashing in the browser, and if it actually is an issue for some devs, they can simply add the other route in their own host-file to get back to the original behaviour. @altinnadmin I've updated to local.altinn.studio I think it makes the most sense, but I think I got confused by the fact that we also have local.altinn.cloud.
This is solely for local development and will reduce the overhead of getting started for new devs.
Yup, and thus very important! :)
We would most likely turn off cashing in the browser
This isn't just related to caching, clearing HSTS in browser is a pain. We can't expect devs to do this after every time they visit altinn.studio, and removing HSTS is not an option.
Idea:
Could we search-replace local.altinn.studio with altinn.studio.localhost in this PR?
Seems to work in all browsers except Safari.
I've verified in Chrome/Edge/Firefox on Windows, perhaps you could verify on Mac @mjulstein ?
This is solely for local development and will reduce the overhead of getting started for new devs.
Yup, and thus very important! :)
We would most likely turn off cashing in the browser
This isn't just related to caching, clearing HSTS in browser is a pain. We can't expect devs to do this after every time they visit altinn.studio, and removing HSTS is not an option.
Idea: Could we search-replace
local.altinn.studiowithaltinn.studio.localhostin this PR? Seems to work in all browsers except Safari.I've verified in Chrome/Edge/Firefox on Windows, perhaps you could verify on Mac @mjulstein ?
I've tested on Mac, and I have edited the readme to account for those changes :) Great suggestion to use *.localhost btw @altinnadmin
SonarCloud Quality Gate failed.
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
0.0% Coverage
0.0% Duplication