quarta-feira, 3 de outubro de 2018

(resolvido) Visual Studio 2017 não consegue executar comandos em repositórios git do BitBucket


Após uma atualização do Visual Studio 2017 não é possível mais executar comandos (push de commits por exemplo) em repositórios git no BitBucket.

O problema aparentemente ocorre apenas para repositórios BitBucket, testei no GitLab e não foi preciso essa intervenção. Não testei outros, mas em pesquisas que fiz realmente só ocorre no citado.

Obs: utilizando o cliente GitTortoise não tive problemas, mas a idéia é resolver a execução de comandos de dentro do Visual Studio.


A Microsoft liberou uma atualização do Git Credential Manager que resolve esse problema, mas são necessários alguns passos com a atualização dos arquivos que são acessados pelo Visual Studio.

1 - Baixar e instalar a versão 1.18.0 (1 de outubro) do Git Credential Manager

Obs.: também havia testado com a versão 1.17.1 (9 de agosto) com sucesso.

Bug Fixes:
  • Ensure the Bitbucket login screen correctly grab focus.
  • Allow Bitbucket access tokens to be cast as credentials, and properly handle personal access tokens used as authentication in network requests.
  • If path is sent use it to set TargetUri.ActualUri

2 - Localizar os arquivos do Git Credential Manager que serão copiados

  • C:\Program Files\Git\mingw64\libexec\git-core (pasta de instalação do GCM)

Ordenando a lista por data descendente serão os 6 primeiros.

3 - Localizar a pasta destino para onde os arquivos acima serão copiados

  • Digitar no Windows (botão Iniciar) "Developer Command Prompt for VS 2017" para chamar o prompt de comando do VS.

  • Executar o comando "set" para descobrir o local definido na variável "DevEnvDir".

    No meu caso: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\

A pasta destino dos arquivos a copiar será:
%DevEnvDir%\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32\libexec\git-core

Feita a cópia por cima dos originais, na próxima tentativa no Visual Studio de execução de algum comando no repositório no BitBucket será exibida uma janela para autenticação (imagem abaixo), após isso não será mais preciso digitar.

terça-feira, 3 de julho de 2018

Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core 2.x and jQuery

Microsoft has greatly simplified ASP.NET Core 2.x implementation of the security implementation on out-of-site request spoofing, that is, someone forging the POST / PUT from another location.
By definition, for the GET and TRACE method there is no protection for this scenario.
With a few simple steps you will be able to implement this level of security in your web application.

1 - In the HTML form of your application add:

  • @Html.AntiForgeryToken()

2 - In the class Controller add the attribute:

  • AutoValidateAntiforgeryToken

So all the methods of the class will be under protection.

Optionally you can work individually by adding to each method the attribute:

  • ValidateAntiForgeryToken

Also worth using the attribute:

  • IgnoreAntiforgeryToken

4 - In the jQuery Ajax call:

     beforeSend: function (xhr) {
            xhr.setRequestHeader("XSRF-TOKEN", $('input:hidden[name="__RequestVerificationToken"]').val());  },

5 - In the Startup class (.cs):

services.AddAntiforgery(o => o.HeaderName = "XSRF-TOKEN");

So when someone tries to do a POST/PUT on some protected API method, the server itself will reject the request by returning an HTTP 400 error code.


  • https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-2.1
  • https://owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

sexta-feira, 2 de fevereiro de 2018

Offline Storage for Progressive Web Apps

Offline Storage for Progressive Web Apps

The Pokedex.org Progressive Web App uses IndexedDB for application state and the Pokemon data set while the Cache API is used for URL addressable resources.
2016 will hopefully be the year we build for network resilience.
Internet connections can be flakey or non-existent on the go, which is why offline support and reliable performance are common features in Progressive Web Apps. In this post, I’ll summarize some ideas around offline data storage for PWAs — think the JSON payloads, images and general static data required to provide a meaningful experience offline.
A recommendation for storing data offline:
For URL addressable resources, use the Cache API (part of Service Worker). For all other data, use IndexedDB (with a Promises wrapper).
Some quick answers to common questions on why:
  • Both APIs are asynchronous (IDB is event based and the Cache API is Promise based). They also work in Web Workers, Window and Service Workers.
  • IDB is available everywhere. Service Workers (and the Cache API) are available in Chrome, Firefox, Opera and are in development for Edge.
  • While IDB doesn’t support Promises, several strong libraries giving us Promise wrappers exist. See below for recommendations. The API has mandatory complexity (transactions, schema versioning) that these libraries also try to smooth over where possible.
  • Native support for IDB Promises has been proposed as have observers.
  • How much can you store? In Chrome and Opera: Your storage is per origin (rather than per API). Both storage mechanisms will store data until the browser quota is reached. Apps can check how much quota they’re using with the Quota Management API. Firefox: no limits, but will prompt after 50MB data stored. Mobile Safari: 50MB max, Desktop Safari: unlimited (prompts after 5MB), IE10+ maxes at 250MB and prompts at 10MB. PouchDB track IDB storage behavior. Future facing: For apps requiring more persistent storage, see the on-going work on Durable Storage.
  • Safari 10 has fixed many long-standing IDB bugs in their latest Tech Previews. That said, some folks have run into stability issues with Safari 10’s IDB and PouchDB have found it to be a little slow. Until more research has been done here, YMMV. Please do test and file browser bugs so the folks @webkit and related OSS library authors can take a look. LocalForage, PouchDB, YDN and Lovefield use WebSQL in Safari by default due to UA sniffing (there wasn’t an efficient way to feature-test for broken IDB at the time). This means these libraries will work in Safari 10 without extra effort (just not using IDB directly).
  • URL addressable resources are typically static resources that surprisingly..live at a URL. For PWAs, you could cache the static files composing your application shell (JS/CSS/HTML files) in the Cache API and fill in the offline page data from IndexedDB. There are no hard and fast rules around this however. Some applications might be sufficiently simple that they can just use the Cache API alone while others may find it valuable to partially cache their JSON payloads in IDB so that in browsers without Cache API support you still get the benefit of some local caching during the session.
  • Debugging support for IndexedDB is available in Chrome (Application tab), Opera, Firefox (Storage Inspector) and Safari (see the Storage tab). Debugging IDB is not currently supported in Edge (however, it is possible to debug the underlying JetDB) — vote here for built in support.
IndexedDB Libraries worth checking out
  • localForage(~8KB, Promises, good legacy browser support)
  • idb-keyval (<500 bytes="" if="" key-value="" li="" need="" only="" promises="" support="" use="">
  • idb (~1.7KB, Promises, also does iteration, indexing)
  • Dexie (~16KB, Promises, complex queries, secondary indices)
  • PouchDB (~45KB (supports custom builds), synchronization)
  • Lovefield(relational)
  • LokiJS (in-memory)
  • ydn-db(dexie-like, works with WebSQL)
Service Worker Libraries worth checking out
  • sw-toolbox (offline caching for dynamic/runtime requests)
  • sw-precache (offline precaching for static assets/application shells)
  • Webpack users can directly use the above or offline-plugin

What about other storage mechanisms?

  • Web Storage (e.g LocalStorage) is synchronous, has no Web Worker support and is size-limited (only strings). Although ideas for async LS have been kicked around in the past, current focus is on getting IndexedDB 2.0in a good state. I would personally use IDB + a library.
  • Cookies have their uses but are synchronous, lack Web Worker support and are size-limited. In previous projects I’ve used js-cookie for handling cookies via JS (~800bytes gzipped). Support for an Async Cookies API is being sketched out right now with a polyfill in the works.
  • WebSQL is asynchronous (callback-based), however it also has no Web Worker support and was rejected by Firefox and Edge but is in Chrome and Safari.
  • File System API is asynchronous too (callback-based) and does work in Web Workers and Windows (albeit with a synchronous API). Unfortunately it doesn’t have much interest outside of Chrome and is sandboxed (meaning you don’t get native file access).
  • File API is being improved over in the File and Directory Entries API and File API specs. A File API library exists and for file-saving, I’ve been using FileSaver.js as a stop-gap. The writable-files proposal may eventually give us a better standards-track solution for seamless local file interaction.

Current and future offline storage work

If offline storage interests you, the below efforts are worth keeping an eye on. I’m particularly excited about Promises support in IndexedDB being possible without the need for a library.

IDB with some sweet await goodness.


Offline storage isn’t quite magical and an understanding of the underlying APIs will go far in helping you make the most out of what we now have available. Whether you prefer to directly use these APIs or work with an abstraction library, take some time to get familiar with your options.
Hopefully this will help craft an offline experience that makes your PWA ✨
With thanks to Nolan Lawson, Joshua Bell (whose work on Open Web Storage and BlinkOn talk heavily inspired this article), Jake Archibald, Dru Knox and others for their previous work in the web storage space.
Update September 2nd 2016 with some more FAQ:
What eviction gotchas exist for IndexedDB and the Cache API? Is it possible to currently guarantee that a response will always be available offline?
An origin is given an amount of space to do with as it pleases. This free space is shared across all forms of origin storage (IndexedDB, Cache API, localStorage etc). This amount given isn’t specified and will vary depending on device and storage conditions (e.g if the device is already pretty constrained).
When web storage is low (under pressure), a UA will clear storage to make space available. This can suck for offline apps and so the recently updated Storage spec defines a “persistent” and “best effort” strategy here with “best effort” being the default. “best effort” means the storage can be cleared without interrupting the user, but means it is less durable for long-term or super critical data. IndexedDB and the Cache API fall into the “best effort” bucket today.
“persistent” storage is not automatically cleared when storage is low and the user will need to manually clear out this storage (via browser settings) themselves. Chrome has been experimenting with support for Persistent Storage under an origin trial, and the latest news suggests it will be shipping in Chrome 55.
How can I tell how much storage space my app is using?
The Quota Management API lets you query for the size of storage space currently used and how much is available to the application. It also enables requesting for more storage if needed. A newer Storage Quota Estimate APItries to make it even easier to discover how much quota an origin is using with support for Promises.

quinta-feira, 8 de junho de 2017

GitLab.com - erro 404 (not found) ao tentar clonar um repositório

Para quem está com problemas sobre não conseguir clonar um repositório do GitLab fica a dica.

Resumindo: o problema é sobre a credencial salva no Windows não aceita pelo GitLab.

Abaixo a tela de erro após tentar clonar pelo TortoiseGit (com qualquer aplicativo daria problema):

Mesmo após tentar configurar as credenciais avulsas o Git insistia em buscar a configuração que estava gravada no Windows (10):

Esse era o motivo, a credencial salva no Windows estava sendo aplicada mesmo eu indicando outra, no caso do GitLab a mensagem de erro retornada não é nada sugestiva diga-se de passagem, sendo retornado um erro HTTP 404, sendo que o erro é de credencial inválida.

No meu caso eu preferi editar a credencial existente com o usuário e senha corretos:

Após a correção o processo de clonagem do repositório funcionou sem problemas:


  • https://gitlab.com

sexta-feira, 17 de março de 2017

LG G3/G4 bootloop não é problema de software, mas de hardware

(reprodução - link original no final)

LG G4 está no centro de uma disputa judicial nos EUA devido a um problema conhecido como bootloop: o aparelho fica na tela de boot e nunca entra no Android.
Segundo o Ars Technica, uma ação civil pública acusa a LG de substituir aparelhos com bootloop por outras unidades com o mesmo defeito, e apenas se o cliente estiver no período de garantia.
Laura Lane e Rosalene Mullins, que fazem parte do processo judicial, compraram dois G4 e eles tiveram o problema de bootloop. A LG realizou a troca, mas os novos smartphones também tinham o problema. Agora no terceiro G4, ambas reclamam de lentidão, engasgos e superaquecimento – sinais de que o bootloop está prestes a ocorrer.
Edward Pistorio, que também faz parte do processo, diz que a LG substituiu duas vezes o G4 dele – e o terceiro já “está manifestando sinais do defeito de bootloop”. Enquanto isso, o G4 da esposa dele parou de funcionar devido ao mesmo problema, só que a LG se recusa a trocá-lo porque a garantia expirou.
O processo alega que o processador está inadequadamente soldado à placa-mãe, tornando-o “incapaz de resistir ao calor”. Inicialmente, os aparelhos começam a sofrer engasgos, travamentos, superaquecimento e reinicialização aleatória. Com o tempo, eles param de funcionar completamente.

No início de 2016, a LG admitiu que o G4 tem problemas de bootloop causados por “mau contato entre os componentes”. (Um usuário do Instructables diz que consertou o smartphone dele após desmontá-lo e aplicar ar quente no processador por vários minutos.) A empresa se comprometeu a resolver o problema de bootloop dentro da garantia.
O problema é que, segundo a ação judicial, ela só estava trocando um aparelho defeituoso por outro:
Apesar desta admissão, a LG não fez um recall nem ofereceu uma solução adequada para os consumidores que compraram o smartphone G4. Em vez disso, ela substituiu aparelhos com defeito dentro do período de garantia de um ano com modelos que tinham o mesmo defeito. E a LG se recusou a fornecer qualquer solução para quem comprou o G4 e teve o problema de bootloop fora do período de garantia.
A ação civil pública, aberta em um tribunal federal da Califórnia, quer compensação por danos “em montante a ser determinado no julgamento”, além de um “programa abrangente para consertar todos os aparelhos da LG com o defeito de bootloop”.
No Brasil, diversas pessoas se queixam do bootloop no Reclame Aqui e em comunidades do Google+, alegando que o LG G4 precisa ir várias vezes para a assistência técnica. Muitos também mencionam problemas de burn-in na tela (distorções e manchas na imagem). Entramos em contato com a LG, que não comentou o caso até a publicação desta matéria.


sexta-feira, 24 de fevereiro de 2017

Quanto vale um iPhone 4S 8GB no iPlace? 80 reais

É isso aí, se você pretende trocar o seu iPhone velho guerreiro, que está em perfeito estado, o iPlace "valoriza" em 80 reais.

...sendo que o preço médio de venda é na casa de 400 reais ou um pouco mais, novo ou usado.

segunda-feira, 19 de dezembro de 2016

Tiradas Sirianas (Siri iOS) #1

Por mais que em termos funcionais e precisão o Google Now esteja bem à frente da Siri, uma coisa é fato, ela tem um senso de humor que o robô da Google não chega nem perto de simular, apesar da piada ser sem graça. 😆