Closed piranna closed 9 years ago
I'll get started on that tomarrow, makes sense for the most part
Check current url to find out where we are
-If an issue-Render Issue View
-If index-Render index view
-If anything else-Render 404
Issue click -> History API -> Render View
Render View
-Get the specified issue-If not there, 404
--Display in rendered View
Great :+1: Issue view only show the issue and the comments (two requests... Reuse issue content when comming from Index view?), we'll left to publish comments as a future task ;-)
http://oauth-io.github.io/oauth-js/
Hum? If it's true, then we could have fixed this... :-D
Hello.js seems to offer the same functionality :-) Good to know there are OAuth libraries for pure server-less apps! :-D
Jeeze man, your google-fu is impecable. Granted I wasn't thinking about it today but these are some good finds!
github oauth serverless
did the trick ;-)
https://developer.github.com/v3/issues/#list-issues-for-a-repository
It's possible to request issues updated from a date, so there's no problem in caching locally the post and later use meaningful post urls or also use lun.r and have a build-in search engine :-)
formula1.github.io/
Check it out. We could probably make the login button look a little bit nicer. I'm also considering making the authentication its own module that can get compiled. I'll do a reply to this gist for being so damn helpful with some comments on what helped/what didn't.
formula1.github.io
That's cool! CSS needs some tune-ups (that big avatars... :-P) but it's really great how it's working! :-D
Check it out. We could probably make the login button look a little bit nicer.
I didn't see the login button anywhere. Maybe it's because I'm not using the page intensively and don't get the limit?
I'm also considering making the authentication its own module that can get compiled.
A reusable module, you say? :+1: :-)
I'll do a reply to this gist for being so damn helpful with some comments on what helped/what didn't.
I didn't fully understand how YQL works here, seems to be a online database that does the request in our behalf and has stored the application secret key, so it doesn't need to be exposed, isn't it? It's a shame that OAuth requires a server to be involved due to that, having the token should be just enough, but if there's no other option... :-/
Avatars
You should have seen it before!
Login Button
If you want to get a 403, go to one of the articles and refresh until it gives you an error. From there, it will show up as "403, try logging in" sort of thing.
Its own module
Yeah, I'll try to tidy it up as a resusable module. That will probably happen tomarrow though.
YQL's involvement
So YQL is an online database, true. However, techinically the table can be specified as just running a script (similar to yahoo pipes). The client secret is technically not secure. If someone decided to brute force select * from yql.storage where name="BRUTE_FORCE_HERE"
they could eventually get your client secret. So the secret is dependent on yql generates keys, the speed non-important keys are being created vs whether they know the yql key generation algorithm and speed of them making bruteforce calls. However, if enough secrets are in YQL, the chances of a successful call also containing a secret becomes better. Essentially, it's likely more work/time than someone wants to spend.
Other improvements
Amoungst the things that should probably be done when it comes to html are
Avatars You should have seen it before!
Maybe I've missed them, previously the post titles were pointing to GitHub. Don't mind :-)
Login Button If you want to get a 403, go to one of the articles and refresh until it gives you an error. From there, it will show up as "403, try logging in" sort of thing.
Now I've seen it ;-) It's shown as an error, this would need some tune-up. Also, it's shown too quickly (about 5-10 reloads), so I think we should go with the IndexedDB thing...
Other improvements
I agree on them.
P.D.: i added you as collaborator of NodeOS so you can push directly to the GitBlog repo, could you be able to take a look so we can join efforts there?
Absolutely, I'll take a look
:+1:
I'm currently moving to a new hardrive, but I'm going to try to start finishing this up today!
:+1: mine died last week, so we are in the same stage... :-P
Just an update on this specific aspect. I looked into jekyll and it seems that redirection isn't possible on wildcards. I was also fooling around with making the 404 page the one page app allowing semantic urls however all 404's give a 404 status code (as they should) and I doubt any webcrawler indexes 404 pages (Which they shouldn't).
Right now I'm going to turn the user system into its own module however I'm fully aware of needing handle the ?_escaped_fragment
and change the current urls into #!
https://support.google.com/webmasters/answer/174992?hl=en
Just an update on this specific aspect. I looked into jekyll and it seems that redirection isn't possible on wildcards. I was also fooling around with making the 404 page the one page app allowing semantic urls however all 404's give a 404 status code (as they should) and I doubt any webcrawler indexes 404 pages (Which they shouldn't).
I don't fully understand your problem, what do you mind by wildcards? In the end, you could do window.location='/'
or something similar...
Right now I'm going to turn the user system into its own module however I'm fully aware of needing handle the ?_escaped_fragment and change the current urls into #! https://support.google.com/webmasters/answer/174992?hl=en
Didn't know os this, it's really cool! :-) Maybe it would be its own module :-P I don't know if there would be some problems with the generation of the static HTML pages for the crawler, but GitHub Pages and Jenkins are build in Ruby and could allow to exec some code to generate them...
By wildcards I mean globs and regex. Ability to match anything. The idea being that
/blog/articles/ARTICLE_ID_HERE
/^\/blog\/articles\/.*$/
-> /article/template
However, jekyll doesn't support .* matching or * matching so I was planning on using 404 to render. If we were to redirect via 404, it doesn't make too much of a difference
/blog/articles/ARTICLE_ID_HERE
404.html
and a 404 header <-This will not be indexed/article/template#ARTICLE_ID_HERE
/article/template
<- This will be indexedThat being said, the base framework is basically done, at this point its about css, maximizing SEO and speed increases.
I don't believe Jenkin's is supported by github page. It seems the special things are here https://help.github.com/categories/github-pages-features/. I considered doing some redirects however that would mean I would have to make a page for every possible number. Some additional customization is here http://jekyllrb.com/docs/configuration/.
I was also attempting to setting the source of the site to the /_site
directory so that I may avoid a difference between production and development sources however You cannot change the source setting
Jekyll is very simple in what it offers. I could potentially fork and try and build glob support in urls to point to a single file (since they allow globs to be supported in includes/excludes but specifically said they don't want regex not once but twice). But I want to get back to my other projects asap.
As such,
I'm handling the important stuff for google here https://github.com/formula1/NodeOS-Blog/blob/master/html/footerjs/blogsingle.js#L1
So this can be closed unless you had somethng else in mind
AFAIK Angular support History API to create paths although being a single-page framework, so it could be used to show pages for each one of the post and probably have a better SEO. The simple path would be to use the issue ID but its ugly, a better way would be to use the issue title but this would require some mapping doing a request to the server to get all the post and later show the correct one, wasting bandwidth.