86 karma · joined March 3, 2019
Good to know.
db-uri = "postgres://authenticator:mysecretpassword@project_name.cloud.neon.tech:5433/postgres" db-schema = "api" db-anon-role = "web_anon"
Regarding Kratos and Hydra is this[1] your PR?
[1]https://github.com/ory/kratos-selfservice-ui-node/pull/149
We evaluated Ory a few months ago. My understanding:
1. Ory Kratos provides session-based authentication and user management.
2. Ory Hydra is a self-managed server that secures access to your applications and APIs with OAuth 2.0 and OpenID Connect.
Basically we want to replace AWS Cognito (which is pretty much abandonware) to secure our API so we needed both applications. Unfortunately we had to put our efforts on hold:
1. Bugs around traits meant we had issues around password change, password recovery and email change/reverifications for our use-case
2. Lack of documentation prevented us making progress on 2FA/WebAuthn
3. Bearer token/Oauth consent flow wasn't available without a lot of work because Kratos and Hydra are not "integrated" [1]. Someone shows how they rolled their own integration [2].
I'd love for someone to advise that we were wrong or misunderstood things or that things have moved on since then!
[1] https://github.com/ory/kratos/issues/273 [2] https://blog.px.dev/open-source-auth/
1. Customer original bill (variable - user provided) e.g. 100
2. Saving (variable - user provided) e.g. 9
3. Saving percentage (calculated) e.g. 9%
4. Billed Percentage (variable based on savings percentage?) e.g. 25% x 9
So you would have a billed percentage "rate card" that depends on variable factors like the customer bill plan, the amount/percentage saved etc? Is that the tricky bit?
Whenever there's no pricing it immediately says "not for me, move on". Maybe that's your intention!
1. Spree: headless ecommerce with REST/GraphQL APIs built using Rails/Ruby. Next.js and Vue starter sites
2. Saleor: headless ecommerce with GraphQL API built using Django/Python. Next.js starter site
3. Reaction/Open Commerce: headless ecommerce with GraphQL API built using Node.js/Javascript
4. Solidus: headless ecommerce with REST API built using Rails/Ruby
5. Medusa: headless ecommerce with REST API built using Node.js/Express/Javascript. Gatsby and Next.js starter sites
6. Sylius: ecommerce built using Symfony/PHP
7. Shuup: ecommerce built using Django/Python. Looks like open source version is dead
8. Vendure: headless ecommerce with GraphQL API built using Node.js/Typescript
Major missing feature for the average user I think would be easy image/binary upload, embedding and preview.
By leveraging Github (and Gitlab please) auth it makes this usable by enterprise which is smart I think.
1. https://docs.microsoft.com/en-us/linkedin/shared/authenticat...
1. https://www.rayt.io 2. https://api-docs.rayt.io/#operation/addSchema 3. https://docs.rayt.io/docs/identityproof/data-receiver/create... 4. https://docs.rayt.io/docs/tutorials/how-it-works-business 5. https://docs.rayt.io/docs/features/form-features
[0] Personally identifying information
0. http://cyberlaw.stanford.edu/blog/2013/12/human-error-cause-...
The insured has a duty to disclose everything that is or would be material to the insurer, even if that information is known only to the insured.
Fraud is entirely separate.
If anyone else is interested, please contact me directly (email in my profile).
The benefits of the surveillance capitalism business model are seeing business values being recalculated as business owners recognise the value of exploiting vast amounts of data collected in the pursuit of a purpose other than for which it was collected. Microsoft for example has been heading in this direction over the last few years through their acquisition of Lynda/LinkedIn, Github and Glint. I expect other SaaS businesses to increasingly exploit this opportunity.
Personally I support the efforts of Brave in this case and there are other potential targets that I think are vulnerable to a similar complaint. It will be interesting to follow the Irish Data Protection Commission's progress on this.
We had started down the track of building a basic version of this for our ski club using MS "Power Apps". Our basic process is: 1. Pre-season: estimate requirements based on previous years and do a few large orders with various suppliers for delivery to coincide with the annual food lift (we can't drive all the way to our club). Primarily this is meat and non perishables such as tinned/packaged items, toileteries and cleaning products. 2. Every few days during the season: perform a stock take of what's on-hand in the club. Send to the catering officer. 3. Catering officer orders according to his/her assessment of requirements. Mainly this will be perishables such as fruit/veges, eggs, bread, milk but later in the season may include other items 4. Items are delivered to common stock room and carried up the mountain by club members. Items are checked off the order list provided by the catering officer and added to various storage areas (fridges/freezers, store room, kitchen pantry etc).
Based on a quick run through the demo system I think grocy will meet our requirements for managing consumables.
Additionally club members staying on a particular night are assigned duties by the lodge leader e.g. breakfast dishes, vegetable prep, cooking dinner. We may be able to use the "Chores" function to help with that.
Personally for home use I would not use this because it would not be practical for our family.
Regarding an additional feature: I would recommend looking at Cozi which we use for a shared family calendar which is really valuable for us. I imagine it would be fairly trivial to add that feature to Grocy.
I'll let you know how we got on with the club. Thanks and hope that helps.